As far as I know and I have read in linker documentation there are 5 output section types: NOLOAD, DSECT, COPY, INFO, OVERLAY but only 2 of them are explained: NOLOAD and OVERLAY. COPY, INFO and DSECT are not explained and everywhere in the internet I can see the same 2 explained and 3 left without a word. Anyone would be so kind to explain what DSECT, COPY and INFO exactly change about output section?
from the official GNU ld documentation (which can be found easily with info ld):
DSECT
COPY
INFO
OVERLAY
These type names are supported for backward compatibility, and are
rarely used. They all have the same effect: the section should be
marked as not allocatable, so that no memory is allocated for the
section when the program is run
Related
I get The reference info was not found in the current environment when I try to do a make on the Adam Chlipala Certified Programming with Dependent Types download software cpdt bundle. The file is LogicProg.v line 155. There were other problems before this (see here). And lots of errors where I had to change [ ] to { } around stuff. But this seems to be the last bug.
The surrounding text mentions that info is no longer available:
with the info tactical. (This tactical is not available in Coq 8.4 as of this writing, but I hope it reappears soon. The special case info_auto tactic is provided as a chatty replacement for auto.)
It was partially replaced by the command Info 1:
(* Instead of: info auto 6 *)
Info 1 auto 6.
Another alternative is to just remove info and skip mentions of it.
ld man here say
-n
--nmagic
Turn off page alignment of sections, and mark the output as "NMAGIC" if possible.
-N
--omagic
Set the text and data sections to be readable and writable. Also, do not page-align the data segment, and disable linking against shared
libraries. If the output format supports Unix style magic numbers,
mark the output as "OMAGIC". Note: Although a writable text section is
allowed for PE-COFF targets, it does not conform to the format
specification published by Microsoft.
--no-omagic
This option negates most of the effects of the -N option. It sets the text section to be read-only, and forces the data segment to be
page-aligned. Note - this option does not enable linking against
shared libraries. Use -Bdynamic for this.
I do understand that theses options are used to make the code (.text) section writable or not, but I don't get the point to align or not the sections, and what is a "NMAGIC" section
On historic (PDP-11) Unix, an executable file's header began with a branch instruction that would jump past the header, to the actual start of the code. When Unix was ported to other processors, that initial PDP-11 branch instruction became fossilized as the "magic number" for the a.out(5) file format. When "pure text" was introduced, initially to allow processes to share their code segments, a new magic number was introduced so that the kernel could tell the difference (there were some important Unix programs that relied on self-modifying code and thus needed to be loaded with writable code segments). The old magic number (0407) was given the name "OMAGIC" -- "old magic" -- and the new magic number (0410) was given the name "NMAGIC", "new magic". The data segment immediately follows the code segment in memory, so when the code segment is made read-only, it must be padded to a page boundary.
Various operating systems and file formats since then introduced other magic numbers; in the last FreeBSD releases to use a.out format, the normal formats were ZMAGIC and QMAGIC, which were introduced to allow page zero in the address space to be unmapped for safety (so that a null-pointer dereference would fault) while still allowing executables to be demand paged (i.e., mmap()ed into the process's address space).
So to answer your question more directly: NMAGIC and OMAGIC are different formats of executable files, not of individual sections. They indicate the desired correspondence between the in-memory and on-disk layouts of the executable. (The reason these numbers are traditionally written in octal rather than hex or decimal is that octal is a natural representation for the instruction format on the PDP-11.) GNU ld uses these names (only) as references to executable formats that have analogous features, even when you are not generating traditional a.out format -- which of course is quite rare today. One particular benefit to using OMAGIC format is that it is more compact than any other format, which may matter in cases like boot loaders where space is limited, there is no demand paging, and there is also no room for any sort of padding.
I've set up a project to use Coverity Scan.
Under Analysis Settings→Project Components I have
Component name Pattern Ignore in analysis
cxxopts .*/src/cxxopts.hpp Yes
STL /usr/include/c++/.* Yes
but still when I go to View defects I see 9 issues, all from files like /usr/include/c++/5.4.1/functional. How do I actually exclude them?
Confusingly, the Overview tab shows
12 Total defects
2 Outstanding
7 Dismissed
3 Fixed
even though View defects shows 9 issues (is that the 7+2? Why are some outstanding and some dismissed, when all should be ignored?)
It looks like a regex pattern, in which case the "++" likely needs some form of escaping. I'm not sure which form, because I don't know how the strings are being interpreted or what kind of regex syntax is being used, but some variant of the following should work:
/usr/include/c\+\+/.*
/usr/include/c\\+\\+/.*
/usr/include/c\\\+\\\+/.*
If none of these work, I'd suggest contacting scan-admin#coverity.com (listed as the contact email for questions on the scan website).
This would also explain why the overview shows results from these files at all.
This question already has answers here:
What does the number in parentheses shown after Unix command names in manpages mean?
(7 answers)
Closed 4 years ago.
I have a simple question I made my self but didn't find any answer and hints.
When I type for the man entries of a command, e.g. "man git", I get the following:
...
DESCRIPTION
...
See gittutorial(7) to get started, then see Everyday Git[1] ...
The Git User's Manual[2] has a more in-depth
introduction.
After you mastered the basic concepts, you can come back to this page to learn what commands Git offers. You can learn more about individual Git
commands with "git help command". gitcli(7) manual page gives you an overview of the command line command syntax.
Formatted and hyperlinked version of the latest Git documentation can be viewed at http://git-htmldocs.googlecode.com/git/git.html.
Could someone explain what are those "See gittutorial(7)...Everyday Git[1]...gitcli(7)" etc.? I mean, I know that they are telling "look at this resource if you want to know the basic concepts, for more info, etc.", but actually how should one interpret it?
What is the meaning of the numbers (like 7, 1, 2, etc..) inside the parenthesis or brackets? And where I can find the resources the manual is telling me to see, do I have to type something in the man prompt, or search on the Internet?
I just would like to ask for an elucidation.
Thank you for your attention!
Man pages are splitted into sections
to access a manual page inside a specific section you prepend the section number before the manpage name, for example try:
man 3 fork
or
man 2 fork
Usually the square braketed numbers are links to additional material in the NOTES section of the manpage (scroll to the bottom)
The parenthesized numbers indicate in which section of the manual the referenced entry appears. Section (1) is commands (programs), section (2) is system call functions, section (3) is general library functions, etc. Some terms have distinct entries in multiple sections. For example, this ...
man 1 printf
... gives a different manual page (from section 1, describing the printf program) than does this ...
man 3 printf
... which gives a page from section 3, describing the printf() function from the C standard library.
It means type man 7 gittutorial for more info. Man page are divided in numbered categories, sometimes overlapping. Use apropos git for instance to see the various possibilities.
The numbers in parentheses, manpage(N), are the manual section, each of the 8 sections covers a different topic.
See man-mages(7) ;) for a list of sections:
man man-pages
And you can open a manpage from a given section by including the number in the command:
man 7 man-pages
The numbers give you a hint of what the manpage will cover, e.g. time(1) is about a command, whereas time(2) is about a system call, and let you specify which section of the manual you're interested in when there's an entry with the same name on different sections.
The numbers between brackets, something[N] are footnotes, usually pointing to places where you can get more information.
I'm trying to write a small example program in Racket's scribble/lp. The source for the project is on Github.
The problem I am experiencing is broken links in the woven html. I've provided it as a gh-page. for the project.
When outputting the document using the command 'Sribble LPexample.scrbl' I get the following warning:
2013 blog > scribble LPexample.scrbl
[Output to LPexample.html]
Warning: some cross references may be broken due to undefined tags:
(dep ((lib "2htdp/image.rkt") ellipse))
(mod-path "racket")
(dep ((lib "2htdp/image.rkt") beside/align))
(dep ((lib "2htdp/image.rkt") rectangle))
(mod-path "scribble/lp")
And the output file places red underlines under the broken links.
The file which gets scribbled is LPexample.scrbl. It's pretty simple:
#lang scribble/manual
#require[scribble/lp-include]
#title{Literate Programming Example}
// snip
#lp-include["LPexample.rkt"]
The section of the literate programming document that sources the broken links is lines 69-86:
which weaves to this:
#chunk[<blue_square>
(rectangle 100 100 "solid" "blue")]
can be composed into other functions this way:
#verbatim|{
#chunk[<blue_square>
(beside/align "bottom"
(ellipse 20 70 "solid" "lightsteelblue")
<blue_square>)]}|
which weaves out to:
#chunk[<example_body>
(beside/align "bottom"
(ellipse 20 70 "solid" "lightsteelblue")
<blue_square>)]
I've been digging through the Racket documentation, of course. But there's really no good example for even cross linking documents using straight scribble/core or scribble/manual, never mind scribble/lp.
I've also tried digging through the source for the Racket documentation, but the scribble files for the the Guide and Reference use so many custom functions and macros and dependencies that I just can't get my brain far enough around it, to dig out a simple "Oh so that's how it's done".
If you want to have the identifiers from your source code automatically hyper-linked, you likely need to do two things.
One is that you need to add for-label requires for any libraries that you want Scribble to recognize. For example, you probably want (require (for-label 2htdp/image)). See this subsection of the docs for more on that.
The other is that if you're hosting the Scribble documents online the documentation links need to point somewhere, and you need to specify where. You can do that with a command-line flag. Something like this:
scribble --html +m --redirect-main http://docs.racket-lang.org/ document.scrbl
You can use different documentation URLs. For example, you might instead link to the pre-release snapshot documentation at http://www.cs.utah.edu/plt/snapshots/current/doc/.
For more details, there is a subsection of the Scribble documentation about handling cross-references: http://www.cs.utah.edu/plt/snapshots/current/doc/scribble/running.html#%28part._xref-flags%29