Memory sections in GNU linker script for Cortex-M4 - linker-scripts

I'm dissapointed, because I can't find an information about memory segmentation. I know that I should divide memory into basic sections such as .text, .data, .bss, .stack, that are used in object files of compiled program. I know that there are many more other sections, some are necessary for C and other for C++. I'm searching information about, which sections should be included in linker script?

It depends on your specific compiler and target architecture which output sections will be present or possibly present. And in your code, you can define input sections with arbitrary names. Your linker script serves to bind symbols from files, or symbols listed in explicitly defined input sections, to the output sections.
The best way to find out which output sections are present, is to just compile and link an example application, and inspect the generated map file (if the map file is not automatically generated, you should adjust your linker options). A map file is not meant for consumption by another tool, but serves as a readable description of what goes in your program, on what location, in which section, and why. Note: in that map file you will also find some section names that are not part of your program, and won't translate to physical bits that get executed or used by your program, but are rather aids for your debugger.
When you don't explicitly map some symbols to an output section, the linker will generally just append all remaining symbols after the last explicitly defined section.
You could therefore also define some kind of 'catch-all' section, that will surely attract all not-yet-assigned-symbols, and then verify whether the output section remains empty.
i.e.
At the end of your SECTIONS block, add
SECTION
{
<snip>
.mustbeempty
{
*(.*) ;
}
ASSERT( SIZEOF( .mustbeempty ) = 0 ) ;
}
More info about linker scripts can be found on many places:
On stackoverflow this has been asked before: Which man page describes ld linker script syntax?
A full explanation can be found in this pdf: https://web.eecs.umich.edu/~prabal/teaching/eecs373-f11/readings/Linker.pdf
red hat has nicely formatted pages: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/index.html
I used this page on scoberlin a lot: http://www.scoberlin.de/content/media/http/informatik/gcc_docs/ld_3.html since the entire ld file syntax is one full html page so it can easily be searched.

Related

Directly adding content to a section from a LD script

I would like to output an extra variable (i.e. data block with a symbol pointing to it) from a LD script. This variable would contain either constant values, or the offsets and sizes of various other variables in the same section of the output file. In other words, I would like to create a header from a LD script.
I could probably do this with a custom C file referencing symbols defined in the LD script, but I wonder whether it would not be possible to avoid that extra step and do it directly in the LD script. Is it possible?
Finally found a way in LD's documentation: (http://www.math.utah.edu/docs/info/ld_3.html#SEC17)
BYTE(expression)
SHORT(expression)
LONG(expression)
QUAD(expression)
By including one of these four statements in a section definition,
you can explicitly place one, two, four, or eight bytes
(respectively) at the current address of that section. QUAD is only
supported when using a 64 bit host or target. Multiple-byte
quantities are represented in whatever byte order is appropriate for
the output file format (see section BFD).
Question still opened in case there are better answers.

Duplicate Outputs in Doxygen

I'm generating developer documentation using Doxygen. It's parsing all of the files correctly, but the output is generating duplicate entries in the member function list and class diagram.
Any ideas?
I had this exact problem, and found that I had accidentally specified a build folder in the INPUT line due to RECURSIVE being on, e.g.,
Example file structure:
./
MyLibrarySources/
Libs/
build/
Doxyfile:
INPUT = ./ MyLibrarySources/ ...
RECURSIVE = YES
This caused Doxygen to parse the headers from two different locations: once from MyLibrarySources/, and once from build/, producing duplicate members and other odd results.
The easy solution is to add your build directory to the EXCLUDE line, e.g.:
EXCLUDE = "build"
This makes Doxygen not parse the same header files in two different locations. And yes, in-source build directories are usually a bad idea, place them elsewhere. In my case, command-line builds not issued from my IDE went there by default.
Edit note: I had incorrectly believed that the source files were being parsed twice because of the double-specification in the INPUT line. This is not the case. Doxygen is smart about this and will not parse the same physical file twice 👍.

Doxygen does not process my source file comments

I'm new with Doxygen, and i have been commenting my functions with the Qt style approach:
/*! .. */
Doxygen however only picks up my header files and does not generate documentation of any text that is within these comments.
The html file rendered, shows a completely empty main page, "Classes' only list the structs
that are found in the header files and "Files" lists only the same header files in the project.
What may cause this behavior, or is this to be expected?
Am i missing something? The only thing i changed in the configuration file was the INPUT directory to be "src".
No errors during compilation, i see that it is preprocessing and parsing my .c files. And at some point it says this, but only for the header files
Generating code for file src/foo.h...
Generating code for file src/bar.h...
etc.
Finally i get some warnings about structs not being documented, but nothing about the functions I want to have actually documented.

Documentation not appearing in doxygen output

I'm trying to document a C API which is all contained in a single C Header file. When I run doxygen, on the file, it's giving me errors for currently undocumented C Macros, but when I add the necessary documentation for macros, although the undocumented errors are cleared, the macros plus documentation do not appear in the doxygen generated html output.
Only a fraction of the documented header file, the structures, actually appears in any doxygen output. I can't see anything in configuration settings or documentation that would assist in clarifying why doxygen does not place documented code from the header file into its generated output.
Does anybody know why this would be the case?
See items 2 and 3 of the FAQ: http://www.doxygen.org/manual/faq.html
In short you are likely missing a comment block with #file to document your header file.

_NT_SYMBOL_PATH format

I'm trying to use windbg more, and I keep having problems with the symbol cache. It isn't clear to me what the format of the string is supposed to be.
I have a few requirements:
use Microsoft's server http://msdl.microsoft.com/download/symbols
use symbols from our software that are archived at \\foo\Build1234
use a local cache at c:\dev\symbols
The archive of symbols from our distributed build at \\foo\Build1234 are not organized as a symbol server. If I understand it correctly, I need to use the cache keyword.
Given these requirements, does this look like a properly formatted srvpath:
cache*\\foo\Build1234;srv*c:\dev\symbols*http://msdl.microsoft.com/download/symbols
Edit:
I just started reading Advanced Windows Debugging and I had misinterpreted how the cache keyword works. I thought it was a way of telling the debugger that the folder is just a folder of files and not a symbol server. After Michael left his comment, I reread the section and see that it indeed works as Michael described.
Now I'm confused by when you use a ; or a * to separate paths/URLs. And when you need the srv* prefix. In the online help for windbg they give this example:
\\someshare\that\cachestar\ignores;srv*c:\mysymbols*http://msdl.microsoft.com/download/symbols;cache*c:\mysymbols;\\anothershare\that\gets\cached
The symbols from \\someshare are not cached, symbols from Microsoft are cached in c:\mysymbols, and c:\mysymbols is used as the cache for any other paths to the right of the cache* directive.
The occasional use of srv* is confusing me -- I don't understand why the first and last paths aren't prefixed with srv*.
Edit 2:
This is slowly starting to make sense to me. The srv directive is used for symbol servers, and not for normal symbol directories. So, I believe the answer to my original question is this:
\\foo\Build1234;cache*c:\dev\symbols;srv*http://msdl.microsoft.com/download/symbols
SRV*C:\dev\symbols*http://msdl.microsoft.com/download/symbols;\\foo\build1234
Should work fine, if \\foo\build1234 is just flat PDB's. Cache isn't needed here; you just need to add the directory to your symbol path.
The cache keyword specifies where you want to cache your symbol files, and is useful for caching symbols locally from non-indexed shares (like \\foo\build1234)
cache*C:\dev\symbols;SRV*C:\dev\symbols*http://msdl.microsoft.com/download/symbols;\\foo\build1234
The above path would store symbols from MS's symbol server and your symbol share to your local machine in C:\dev\symbols.
To debug symbol issues using windbg, do
!sym noisy
.reload <some exe or DLL in your session>
And then do some action that would force the PDB to be loaded. You'll see where windbg is looking for files, and if it rejects a PDB why it did so.
!sym quiet
Will then suppress symbol prompts.
Here's a detailed post on debugging issues with symbols loading.
Loading symbols in Windbg