Why do some linux kernel section names use a single . and others use two
For example .data..page_aligned and .data..init_task vs .data.unlikely and .data.once
Does the number of . have a specific meaning
Thanks
I have read the ld and kernel documentation and not found any information
Section name .data..init_task consists from 3 parts:
Prefix .data.
Delimiter ..
Name of the subsection .init_task.
Since the name of the subsection starts with dot, the section name contains the sequence of two dots.
The section name .data.unlikely consists from 3 parts too, but the name of the subsection - unlikely - is not started with dot.
Related
I'm using ESNACC for compiling multiple ASN source files to C code. For ease of understanding, I will explain the scenario here as succintly as possible:-
FileA.asn1 contains the following:-
FileA DEFINITIONS ::=
BEGIN
A ::= SEQUENCE
{
AContent [0] OCTET STRING (CONTAINING FileB.B)
}
END
FileB.asn1 contains the following:-
FileB DEFINITIONS ::=
BEGIN
B ::= SEQUENCE
{
BElem1 [0] INTEGER,
BElem2 [1] INTEGER
}
END
I used ESNACC to compile both files in one command. Upon analysing the C source files generated, I observed that the AContent field will be decoded as a constructed OCTET STRING (the data being received in the application guarantees that the field will be specified as constructed) with its contents being filled into a simple string. This means that FileB does not come into the picture at all. I was hoping that AContent would be further decoded with a structure of FileB being filled, so that I can easily access the elements within. This does not seem to be the case.
I'm fairly new with ASN1, so please let me know if my understanding is wrong in any way.
Is ESNACC not capable of generating code for supporting CONTAINING keyword properly?
Are there other compilers that are able to do this?
Can this be done by using ESNACC in any way?
If this cannot be done using ESNACC, and I don't want to use any other compiler, how would I access the contents within AContent at runtime easily?
I am not sure of the capabilities of ESNACC, but there are many other compilers that support the CONTAINING keyword. An excellent list of compilers can be found at https://www.itu.int/en/ITU-T/asn1/Pages/Tools.aspx which is part of the ITU-T ASN.1 Project.
Heimdal's ASN.1 compiler (lib/asn1/) has support for the funky Information Object System syntax extensions that allow you to declare things like what all goes into Certificate Extensions (for example), and the generated code will decode everything recursively in one go.
Lets say there is a library/API or a bunch of code I want to use (written by someone else) and it's stored in an arbitrary folder (like C:\randoAPIs\coolStuff\includes). Let say my main.c is in a different folder like C:\MyCProjects\coolProject and to use the coolStuff API, I add this include path to my IDE and add #include "coolStuff.h"; and it works fine.
Here's the question:
Lets say that "coolStuff.h" itself includes some other header file like #include "boringStuff.h"; Where does the compiler look for boringStuff.h? Is is in my main.c folder? or in coolStuff's includes folder? Any/all folders in my include path? Or is this a compiler specific issue and I should just go read that documentation
It is completely implementation-defined. C11 6.10.2p3:
3 A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
# include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original directive.
Notice that the #include "coolStuff.h" need not be supported. Additionally #include "coolStuff.h" can even map to something like #include <COOLSTUF.H>. C11 6.10.2p5:
5 The implementation shall provide unique mappings for sequences consisting of one or more nondigits or digits (6.4.2.1) followed by a period (.) and a single nondigit. The first character shall not be a digit. The implementation may ignore distinctions of alphabetical case and restrict the mapping to eight significant characters before the period.
It is the compiler dependant but I would suggest to add your own include directory in your project and keep your include files there. Then just add this path(s) to the include search list in your compiler. For example for gcc (windows) -I"path"
For example: man(1), find(3), updatedb(2)?
What do the numbers in parentheses (Brit. "brackets") mean?
It's the section that the man page for the command is assigned to.
These are split as
General commands
System calls
C library functions
Special files (usually devices, those found in /dev) and drivers
File formats and conventions
Games and screensavers
Miscellanea
System administration commands and daemons
Original descriptions of each section can be seen in the Unix Programmer's Manual (page ii).
In order to access a man page given as "foo(5)", run:
man 5 foo
The section the command is documented in the manual. The list of sections is documented on man's manual. For example:
man 1 man
man 3 find
This is useful for when similar or exactly equal commands exist on different sections
The reason why the section numbers are significant is that many years ago when disk space was more of an issue than it is now the sections could be installed individually.
Many systems only had 1 and 8 installed for instance. These days people tend to look the commands up on google instead.
As #Ian G says, they are the man page sections. Let's take this one step further though:
1. See the man page for the man command with man man, and it shows the 9 sections as follows:
DESCRIPTION
man is the system's manual pager. Each page argument given
to man is normally the name of a program, utility or func‐
tion. The manual page associated with each of these argu‐
ments is then found and displayed. A section, if provided,
will direct man to look only in that section of the manual.
The default action is to search in all of the available sec‐
tions following a pre-defined order ("1 n l 8 3 2 3posix 3pm
3perl 5 4 9 6 7" by default, unless overridden by the SEC‐
TION directive in /etc/manpath.config), and to show only the
first page found, even if page exists in several sections.
The table below shows the section numbers of the manual fol‐
lowed by the types of pages they contain.
1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions eg /etc/passwd
6 Games
7 Miscellaneous (including macro packages and conven‐
tions), e.g. man(7), groff(7)
8 System administration commands (usually only for root)
9 Kernel routines [Non standard]
A manual page consists of several sections.
2. man <section_num> <cmd>
Let's imagine you are Googling around for Linux commands. You find the OPEN(2) pg online: open(2) — Linux manual page.
To see this in the man pages on your pc, simply type in man 2 open.
For FOPEN(3) use man 3 fopen, etc.
3. man <section_num> intro
To read the intro pages to a section, type in man <section_num> intro, such as man 1 intro, man 2 intro, man 7 intro, etc.
To view all man page intros in succession, one-after-the-other, do man -a intro. The intro page for Section 1 will open. Press q to quit, then press Enter to view the intro for Section 8. Press q to quit, then press Enter to view the intro for Section 3. Continue this process until done. Each time after hitting q, it'll take you back to the main terminal screen but you'll still be in an interactive prompt, and you'll see this line:
--Man-- next: intro(8) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ]
Note that the Section order that man -a intro will take you through is:
Section 1
Section 8
Section 3
Section 2
Section 5
Section 4
Section 6
Section 7
This search order is intentional, as the man man page explains:
The default action is to search in all of the available sections follow‐
ing a pre-defined order ("1 n l 8 3 2 3posix 3pm 3perl 5 4 9 6 7" by default, unless overrid‐
den by the SECTION directive in /etc/manpath.config)
Why did they choose this order? I don't know (please answer in the comments if you know), but just realize this order is correct and intentional.
Related:
Google search for "linux what does the number mean in parenthesis after a function?"
SuperUser: What do the parentheses and number after a Unix command or C function mean?
Unix & Linux: What do the numbers in a man page mean?
Note also that on other unixes, the method of specifying the section differs. On solaris, for example, it is:
man -s 1 man
It indicates the section of the man pages the command is found in. The -s switch on the man command can be used to limit a search to certain sections.
When you view a man page, the top left gives the name of the section, e.g.:
User Commands printf(1)
Standard C Library Functions printf(3C)
So if you are trying to look up C functions and don't want to accidentally see a page for a user command that shares the same name, you would do 'man -s 3C ...'
Wikipedia details about Manual Sections:
General commands
System calls
Library functions, covering in particular the C standard library
Special files (usually devices, those found in /dev) and drivers
File formats and conventions
Games and screensavers
Miscellanea
System administration commands and daemons
I was inspecting the preprocessed output generated by GCC, and I see a lot of these in the .i file that I generated using the -save-temps flag:
# 8 "/usr/include/i386-linux-gnu/gnu/stubs.h" 2 3 4
What do the numbers before and after the absolute path of stubs.h mean? It seems to be some kind of debugging information that is inserted by the preprocessor and allows the compiler to issue error messages referring to this information. These lines do not affect the program itself, but what specifically is each number for?
Based on the documentation the number before the filename is the line number. The numbers after the file name are a flag and mean the following:
1 indicates the start of a new file.
2 indicates returning to a file (after having included another file).
3 indicates that the following text comes from a system header file, so certain warnings should be suppressed.
4 indicates that the following text should be treated as being wrapped in an implicit extern "C" block.
In an LD linker script I have the following fragment in the SECTIONS section:
. = (__BUFFER_LOCATION_);
BUFFER . : { } > EXTERNAL_MEM
where __BUFFER_LOCATION_ is defined to some address and EXTERNAL_MEM is defined in the MEMORY section.
In the C program, I have a global buffer declared as:
char outbuf[4096] __attribute__((section("BUFFER")));
It can be seen that the linker script does not mention any input section named BUFFER, but the output section is named as such.
When compiling the program I see that the linker placed the buffer in the supposed address (BUFFER_LOCATION), although the input section was not defined in the LDF. When I remove the attribute from the source, the buffer is placed in a completely different address.
So, I assume that by default, an output-section-command of type "input section description" adds the output section's name to the input sections list implicitly, unless defined somewhere else. However, reading the manual, I could not find a description of such behaviour.
Did I miss something, or is it an "undocumented feature"?
Yes, an output section will automatically match input sections with the same name, unless a different output section mentions them explicitly.
This is documented under Orphan Sections (emphasis mine):
Orphan sections are sections present in the input files which are not explicitly placed into the output file by the linker script. The
linker will still copy these sections into the output file by either
finding, or creating a suitable output section in which to place the
orphaned input section.
If the name of an orphaned input section exactly matches the name of
an existing output section, then the orphaned input section will be
placed at the end of that output section.
If there is no output section with a matching name then new output
sections will be created...