ARM Architecture

Analyzing the Linker Map file with a bit of assist from the ELF and the DWARF


Whenever you’re writing firmware, there all the time comes a time when you should test the assets consumed by your efforts – maybe since you’re working out of RAM or Flash otherwise you wish to optimize one thing. The map file generated by your linker is a useful gizmo to help within the useful resource evaluation. I wished to filter and kind the information generated in an interactive method so I wrote a C# WinForms software that reads the information from the map and presents it in a listing view (utilizing the superior ObjectListView management). Along with a “module” or file primarily based break up of assets consumed it additionally exhibits you some info not current within the map file like all of the International and Static symbols (each capabilities and variables) used within the undertaking. A screen-shot of the applying is proven under.

The code may be downloaded from GitHub


The appliance was developed whereas I used to be writing firmware for the FT900 micro-controller which is a brand new 32 bit micro-controller by FTDI . Nonetheless because the FT32 toolchain relies on GCC, the applying code may be simply configured/up to date to work with different GCC + BINUTILS primarily based toolchains (I’ve tried it on Microchip’s XC16 toolchain).

On this put up I’ll first discuss concerning the information that is uncovered (and never uncovered) in a map file adopted by an outline of this system itself.

The reminiscence map of a fundamental program

A easy embedded system sometimes has the reminiscence map proven under (ignoring peripheral reminiscence). On the highest stage this system may be divided into elements – the code and the information it manipulates. The code in an embedded system goes into the flash the the information goes into the RAM if it is mutable and flash or RAM if it is read-only. The info utilized by a program may be break up into statically allotted international information areas – the initialized DATA section and the zero-initialised BSS section and the runtime allotted reminiscence – the Stack and the Heap.

   ,'''''''''''''''`.0x00000000
   |                |
   |     DATA       |
   |________________|
   |                |
   |     BSS        |
   |________________|
   |       |        |
   |       |        |
   |       |        |
   |       V        |
   |     HEAP       |
   |                |
   |                |
   |                |
   |     STACK      |
   |       ^        |
   |       |        |
   |       |        |
   |       |        |RAM_MAX_ADDRESS
   '`''''''''''''''''

That is the what the reminiscence appears to be like like after we are executing a program. Nonetheless there was a time in house earlier than the large bang when this system was dwelling completely on the flash and the RAM was only a jumble of random bits. How did it come to be that when this system was working the worldwide information that this system entry occur to have the proper values and the reminiscence map appears to be like good and orderly as above? The reply is that this system executable accommodates bootstrap code that initializes the RAM to this system right reminiscence map earlier than any of the code that refers the information executes. On C primarily based programs this boot code is known as the ctr0 (the C runtime zero).

What this implies is that the preliminary values of all the information {that a} program makes use of should itself be saved in this system executable file, in any other case there isn’t a method that the RAM may be initialized by the crt0. Normally this information is saved after all of the code in this system. The standard map of a bin/hex file is proven under

   ,'''''''''''''''''''''|FILE_START
   |_/InterruptVectors_|
   | _/ _/ _/ _/ _/ |
   |_/REST OF/CODE _/ _|
   | INSTRUCTIONS_/ _/ |
   .......................
   |'    ':..:'    ':..:'|
   |. INITIAL:VALUES:'':.|
   |':OF VARIABLES:IN   '|
   |.:DATA SEGMENT:.    .|
   L_____________________|FILE_END

As a consequence, while you declare a worldwide variable initialized to some non-zero worth, you not solely eat RAM but additionally Flash!

Fortunately, again within the day when males did not shave their chests somebody discovered that a lot of the globals are often initialized to zero, and we may avoid wasting flash house if we put all of those zero-initialized globals in a separate block of RAM, and simply specify the beginning deal with + size of this part. Thus the BSS was born and claims all these globals left uninitialized by lazy programmers together with these particularly initialized to zero.

The main points of this reminiscence map used throughout execution and whereas constructing the executable is specified within the linker script file. The FT32 linker script file appears to be like like this:

MEMORY
{
  flash     (rx)   : ORIGIN = 0, LENGTH = 150K
  ram       (rw!x) : ORIGIN = 0x800000, LENGTH = 32K
}
SECTIONS
{
  .textual content :
  {
    ./crt0.o(.textual content*)
    *(.textual content*)
    *(.strings)
    *(._pm*)
    *(.init)
    *(.fini)
     _etext = . ;
    . = ALIGN(4);
  }  > flash
  .information   : AT (ADDR (.textual content) + SIZEOF (.textual content))
  {
    . = ALIGN(4);
    __data = .;
    *(.information)
     *(.information*)
     *(.rodata)
    *(.rodata*)
     _edata = . ;
  }  > ram
  . = ALIGN(4);
  .bss  SIZEOF(.information) + ADDR(.information) :
  {
     _bss_start = . ;
    *(.bss)
    *(COMMON)
     _end = . ;
  }  > ram
   __data_load_start = LOADADDR(.information);
   __data_load_end = __data_load_start + SIZEOF(.information);

This file is enter to the linker, and permits the linker to map the textual content/information/bss areas in each object file into actual bodily addresses and in addition influences the merging of all of the sections collectively into the ultimate executable file. Refer the LD documentation for extra info on the syntax of the script. For our intents we are able to be aware that the sections named .textual content, .strings and many others go into the .textual content section within the flash and .information, rodata, *bss and many others go into the ram. The .information section is itself saved after the top of the .textual content section utilizing the AT() directive.

To see the linker script being utilized in a construct, use the –verbose choice with LD.

Decoding a Map File

A map file may be generated by passing the –print-map > MyMapFile.txt string to LD. As well as the –cref choice will print the cross-reference desk which may be very helpful while you wish to observe down references to symbols. Scrolling down the map file you may encounter a piece named Linker script and reminiscence map. This accommodates a breakdown of the reminiscence contribution of each file that was linked into the ultimate picture.

As an instance the evaluation I’ve created a easy undertaking of two information. All the reasons will probably be primarily based on this easy undertaking. Compiling this undertaking with the next

'Constructing file: ../predominant.c'
'Invoking: FT90x GCC Compiler'
ft32-elf-gcc -I"C:/Program Information (x86)/FTDI/FT90x Toolchain/Toolchain/{hardware}/embrace" -O0 -g -fvar-tracking -fvar-tracking-assignments -Wall -c -fmessage-length=0 -ffunction-sections -MMD -MP -MF"predominant.d" -MT"predominant.d" -o "predominant.o" "../predominant.c"
'Completed constructing: ../predominant.c'
' '
'Constructing file: ../take a look at.c'
'Invoking: FT90x GCC Compiler'
ft32-elf-gcc -I"C:/Program Information (x86)/FTDI/FT90x Toolchain/Toolchain/{hardware}/embrace" -O0 -g -fvar-tracking -fvar-tracking-assignments -Wall -c -fmessage-length=0 -ffunction-sections -MMD -MP -MF"take a look at.d" -MT"take a look at.d" -o "take a look at.o" "../take a look at.c"
'Completed constructing: ../take a look at.c'
' '
'Constructing goal: MapParser.elf'
'Invoking: FT90x GCC Linker'
ft32-elf-gcc -L"C:/Program Information (x86)/FTDI/FT90x Toolchain/Toolchain/{hardware}/lib" -Wl,--gc-sections -Wl,--entry=_start -Wl,--print-map > Linker.map -Xlinker --cref -Xlinker --verbose -o "MapParser.elf"  ./predominant.o ./take a look at.o   -lc -lstub -lft900
'Completed constructing goal: MapParser.elf'

The textual content area of the instance undertaking appears to be like like this:

.textual content           0x00000000     0xf080
 *(.textual content*)
 .textual content          0x00000000      0x310 /cygdrive/c/Program Information (x86)/FTDI/FT90x Toolchain/Toolchain/instruments/bin/../lib/gcc/ft32-elf/5.0.0/crti-hw.o
                0x00000000                _start
                0x00000090                _exithook
                0x000000fc                _exit
                0x0000030c                nullvector
                0x00000310                __gxx_personality_sj0
 .textual content.StaticFunc
                0x00000310       0x20 ./predominant.o
 .textual content.GlobalFunc
                0x00000330       0x20 ./predominant.o
                0x00000330                GlobalFunc
 .textual content.predominant     0x00000350       0x44 ./predominant.o
                0x00000350                predominant
 .textual content.StaticFunc
                0x00000394       0x38 ./take a look at.o
 .textual content.Check     0x000003cc       0x14 ./take a look at.o
                0x000003cc                Check
                ....

We are able to see that the .textual content section begins at deal with 0x00000000 and has a dimension of 0xF080 bytes. The primary module within the .textual content section is a file referred to as ctri-hw.o of dimension 0x310 bytes and there are 4 international capabilities outlined on this file. The –ffunction-sections choice has ensured that every perform is compiled in a separate part, which permits the linker (through -Wl,–gc-sections) to later take away any capabilities that aren’t referred to as from the ultimate executable.

Comparable map info is accessible for the .information and .bss segments. Nonetheless static symbols within the information and bss segments are lacking!

Getting the module clever breakdown of reminiscence is a straightforward matter of studying the strains akin to the .o information and extracting the dimensions.

The Cross Reference Desk

The cross reference desk seems under the reminiscence map and exhibits you a listing of all the worldwide symbols within the undertaking. The primary line signifies the file by which the image is outlined and following strains point out all of the places that the image is used. That is extraordinarily helpful to trace down “rogue modules” that use stuff they should not be utilizing.

Cross Reference Desk
Image                                   File
BSSGlobal                                ./predominant.o
DataGlobal                               ./predominant.o
GlobalFunc                               ./predominant.o     ----> The above 3 symbols aren't accessed outdoors predominant.o
Check                                     ./take a look at.o     ----> The image "Check" is outlined in take a look at.o
                                         ./predominant.o     ----> The image "Check" is referenced in predominant.o

Searching down statics with Some ELF Magic

The absence of static symbols within the map file is annoying for the conscientious programmer who has used static variables and capabilities liberally to help within the ideas of information encapsulation and in addition to permit the compiler to optimize higher. In truth if we had not used the –ffunction-sections choice static capabilities would even have been lacking from the map. Thankfully there are some methods round this limitation.

For many embedded programs the ultimate output of the construct course of is a BIN or HEX file that may be programmed into the microcontroller flash. Nonetheless earlier than we get to the HEX file, the linker really produces one other executable file from which we extract the .textual content section to get the hex file. There are lots of codecs for this executable file, COFF and ELF being the most typical. We’ll take into account ELF as it is the extra versatile format. Sometimes many embedded toolchains generate each the ELF and the HEX file in the identical output listing.

Assuming you will have managed to pay money for the ELF executable in your undertaking, we are able to attempt to get extra some info from it by utilizing BINUTILS packages, that are hopefully a part of your toolchain distribution. Along with containing all of the segments of a program (as outlined within the linker script), the ELF picture additionally accommodates a Image Desk which lists all the worldwide (static and non-static) symbols within the executable. Utilizing READELF to readout the image desk of our undertaking outcomes on this output

$ C:Program Information (x86)FTDIFT90x ToolchainToolchaintoolsbin> .ft32-elf-readelf.exe -s "MapParserTest_FT32DebugMapParser.elf"
Image desk '.symtab' accommodates 342 entries:
Num:    Worth  Dimension Sort    Bind   Vis      Ndx Title
 0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
 1: 00000000     0 SECTION LOCAL  DEFAULT    1 
 2: 00800000     0 SECTION LOCAL  DEFAULT    2 
 3: 00800000     0 SECTION LOCAL  DEFAULT    3 
....
142: 00800a48    40 OBJECT  GLOBAL DEFAULT    3 __mprec_tinytens
143: 0000a0b4    84 FUNC    GLOBAL DEFAULT    1 _lseek_r
144: 0000d31c   204 FUNC    GLOBAL HIDDEN     1 __eqdf2
145: 0000030c     0 NOTYPE  GLOBAL DEFAULT    1 nullvector
146: 0000ba94     0 NOTYPE  GLOBAL HIDDEN     1 __prolog_$r28
147: 0000b828     0 NOTYPE  GLOBAL HIDDEN     1 __epilog24_$r19
148: 00000410    60 FUNC    GLOBAL DEFAULT    1 printf
...

Now we are able to see all of the static symbols too together with their addresses. However we nonetheless haven’t got a straightforward option to see their dimension and supply file identify. Seems BINUTILS has a program referred to as NM that’s written for exactly this objective! Working NM with choices to type by dimension and point out line numbers produces this output.

$ C:Program Information (x86)FTDIFT90x ToolchainToolchaintoolsbin> .ft32-elf-nm.exe --print-size --size-sort --line-numbers "MapParserTest_FT32DebugMapParser.elf" 
00800d20 00000004 B BSSGlobal
00800084 00000004 D DataGlobal
00800098 00000004 d FuncScopeStatic.2411
0080008c 00000004 d FuncScopeStatic.2413
00800090 00000004 d FuncScopeStatic.2417
00800ce4 00000004 b StaticBSSGlobal
00800ce8 00000004 b StaticBSSGlobal
00800094 00000004 d StaticDataGlobal
00800088 00000004 d StaticDataGlobal
....
00000330 00000020 T GlobalFunc  /cygdrive/c/Customers/eGov/workspace/MapParser/Debug/../predominant.c:15
00000310 00000020 t StaticFunc  /cygdrive/c/Customers/eGov/workspace/MapParser/Debug/../predominant.c:10
00000394 00000038 t StaticFunc  /cygdrive/c/Customers/eGov/workspace/MapParser/Debug/../take a look at.c:8

Now we now have the sizes of all of the symbols and the supply information of a lot of them. NM hasn’t listed the road numbers for static variables once more sadly. Thus our journey continues into the land of the dwarves.

Meet the DWARF

Anybody who has used a debugger is aware of that the debugger shouldn’t be blind to static variables and is ready to establish the information by which they had been born. Thus all we now have to do is look into the data that the debugger makes use of to resolve our downside. Dwarf is a typical debugging info commonplace that everybody makes use of. The DWARF debug info is itself saved contained in the ELF file in separate “debug” sections. We are able to extract the debug info utilizing OBJDUMP or READELF. (The software makes use of readelf as xc16 objdump appears to be unable to extract debug data)

Dwarf organizes info when it comes to Compilation Models which is one other method of claiming information. Every compilation unit has a tree of data related to it which incorporates all of the capabilities and variables (amongst quite a lot of different issues) outlined in that file. Extracting the dwarf_info section provides us:

$ .ft32-elf-objdump.exe --dwarf=data path_to_elf > path_to_op_file
  Compilation Unit @ offset 0x0:
   Size:        0x1a5 (32-bit)
   Model:       4
   Abbrev Offset: 0x0
   Pointer Dimension:  4
 <0><b>: Abbrev Quantity: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (oblique string, offset: 0x6d): GNU C11 5.0.0 20150310 (experimental) -g -O0 -fvar-tracking -fvar-tracking-assignments -fmessage-length=0 -ffunction-sections
    <10>   DW_AT_language    : 12   (ANSI C99)
    <11>   DW_AT_name        : (oblique string, offset: 0x2e): ../predominant.c
    <15>   DW_AT_comp_dir    : (oblique string, offset: 0x134): /cygdrive/c/Customers/eGov/workspace/MapParser/Debug
    <19>   DW_AT_ranges      : 0x0
    <1d>   DW_AT_low_pc      : 0x0
    <21>   DW_AT_stmt_list   : 0x0
.....
 <1><234>: Abbrev Quantity: 6 (DW_TAG_subprogram)
    <235>   DW_AT_name        : (oblique string, offset: 0x4f): StaticFunc
    <239>   DW_AT_decl_file   : 1
    <23a>   DW_AT_decl_line   : 8
    <23b>   DW_AT_prototyped  : 1
    <23b>   DW_AT_low_pc      : 0x394
    <23f>   DW_AT_high_pc     : 0x38
    <243>   DW_AT_frame_base  : 1 byte block: 9c    (DW_OP_call_frame_cfa)
    <245>   DW_AT_GNU_all_call_sites: 1
    <245>   DW_AT_sibling     : <0x285>
....
 <1><147>: Abbrev Quantity: 7 (DW_TAG_variable)
    <148>   DW_AT_name        : (oblique string, offset: 0x113): StaticDataGlobal
    <14c>   DW_AT_decl_file   : 1
    <14d>   DW_AT_decl_line   : 6
    <14e>   DW_AT_type        : <0x64>
    <152>   DW_AT_location    : 5 byte block: 3 88 0 0 0    (DW_OP_addr: 88)
 <1><158>: Abbrev Quantity: 7 (DW_TAG_variable)
    <159>   DW_AT_name        : (oblique string, offset: 0xe): StaticBSSGlobal
    <15d>   DW_AT_decl_file   : 1
    <15e>   DW_AT_decl_line   : 7
    <15f>   DW_AT_type        : <0x64>
    <163>   DW_AT_location    : 5 byte block: 3 e4 c 0 0    (DW_OP_addr: ce4)
 <1><169>: Abbrev Quantity: 13 (DW_TAG_variable)
    <16a>   DW_AT_name        : (oblique string, offset: 0x119): DataGlobal
    <16e>   DW_AT_decl_file   : 1
    <16f>   DW_AT_decl_line   : 4
    <170>   DW_AT_type        : <0x64>
    <174>   DW_AT_external    : 1
    <174>   DW_AT_location    : 5 byte block: 3 84 0 0 0    (DW_OP_addr: 84)
 <1><17a>: Abbrev Quantity: 13 (DW_TAG_variable)
    <17b>   DW_AT_name        : (oblique string, offset: 0x14): BSSGlobal
    <17f>   DW_AT_decl_file   : 1
    <180>   DW_AT_decl_line   : 5
    <181>   DW_AT_type        : <0x64>
    <185>   DW_AT_external    : 1
    <185>   DW_AT_location    : 5 byte block: 3 20 d 0 0    (DW_OP_addr: d20)
.....

The primary factor within the tree recognized with the tag <0> is the compilation unit which occurs to be predominant.c. Subsequent parts associated to predominant.c are recognized by tags grater than 0. Observe that capabilities are recognized with the tag DW_TAG_subprogram. DW_AT_low_pc signifies the begin deal with of the perform, this is similar as what’s indicated by the NM output begin deal with. DW_AT_high_pc signifies the dimension in bytes of the perform. Equally variables are recognized by the tag DW_TAG_variable and DW_OP_addr signifies the beginning deal with in RAM of the variable.

Thus on condition that we now have the image record from NM, we simply have to seek out the compilation unit corresponding to every of the symbols at a specific deal with. The mixture of Image Title and (runtime) Tackle uniquely locates all international capabilities and variables even when they’re declared static and have a number of definitions throughout completely different information.

Word that to generate the utmost debug info, you need to use the -g3 LD choice. The additional debug info solely goes into the ELF file and never the binary/HEX file so usually there should not be any penalty when it comes to microcontroller assets by including the -g3 choice into the construct.

Implementation particulars

Now that I’ve defined how the information may be obtained, I’ll briefly cowl the small print of the MapViewer software program in order that the reader can modify the code to swimsuit his or her goal.

Person Interface

The UI is principally made up of two record views – one itemizing the file/module clever break up of the executable and one other itemizing all of the symbols within the undertaking. Filters can be utilized to see the contribution of a subset of information and/or symbols. Filtering a bunch of information robotically filters the symbols within the group. .

The settings view is used to set the paths to the map/elf file, and the BINUTILS paths for NM and OBJDUMP. The mapping of enter sections to the default output sections of TEXT, DATA and BSS can also be specified.

Module View

The module view exhibits the contribution of every object file to the TEXT, DATA and BSS sections outlined within the linker script. The knowledge is gathered by parsing the “Reminiscence Map” part within the map file. Instance strains of curiosity are:

 .textual content._write   0x0000aca0       0x34 /cygdrive/c/Program Information (x86)/FTDI/FT90x Toolchain/Toolchain/instruments/bin/../lib/gcc/ft32-elf/5.0.0/../../../../ft32-elf/lib/libstub.a(stdio.o)
                0x0000aca0                _write
 .information          0x00800084       0x10 ./predominant.o
                0x00800084                DataGlobal
 .information          0x00800094        0x8 ./take a look at.o
  *(.bss)
 .bss           0x00800ce4        0x4 ./predominant.o
 .bss           0x00800ce8        0x4 ./take a look at.o

Linker Optimizations on strings

You would possibly discover that the precise dimension of the information section is lower than what’s obtained by summing the information contributions of every module. This seems to be as a result of the linker does some optimizations to merge frequent string literals throughout modules throughout the rodata sections. String literals inside a file are saved within the rodata.str1.4 part by GCC and are marked for linker optimization. The scale earlier than optimization is indicated within the MAP file by (dimension earlier than enjoyable)

Image View

To get the symbols, we run NM on the ELF file and extract the symbols sorted by dimension. The SEC column signifies which part the image goes into (Textual content = T, Knowledge = D and BSS = B). The International column identifies International Symbols (G), Static Symbols (S) and “Hidden” symbols (H). I outline “Hidden” symbols as these symbols which might be seen within the Map file however are absent within the NM output; this isn’t the “correct” classification as in case you have a look at the ELF image desk there are quite a lot of different symbols marked as Hidden. Discovering the dimensions of those hidden symbols is a bit difficult; for now I discover the dimensions by subtracting the sizes of the symbols addresses within the Map file whereas assuming that the overall dimension of all of the symbols is the same as the module dimension. This algorithm will give incorrect outcomes if the module accommodates non-hidden symbols. I may presumably discover the proper dimension by taking a look at info from the ELF image desk; however that is method deep into the valley of diminishing returns and probably not value perusing for now.

The symbols proven within the image view will probably be filtered in line with the information chosen within the module view. To reset the image view to indicate all symbols, click on the reset syms button. Rows within the image view may be filtered simply because the module view.

Actuals

As each the sum of modules and symbols needn’t all the time add as much as the precise assets consumed, there is a third show that exhibits the precise dimension reported within the Map file. That is calculated by summing the contents of the overall “section dimension” within the Map file. i.e. strains corresponding to these

.information           0x00800000      0xce4 load deal with 0x0000f080
.textual content           0x00000000     0xf080

Observations

Trying on the image output for the take a look at undertaking, you may see that the names of static variables with perform scope (static unsigned int FuncScopeStatic) have been mangled with a .NNNN suffix. That is how GCC handles a couple of (static) variable with the identical identify inside a file. Static variables/capabilities with the identical identify however outlined in several information don’t should be mangled, because the compiler solely sees one file at a time.


Merely including up the sizes of all of the symbols is not going to usually equal the dimensions of the modules or the precise dimension of the assorted sections. One of many causes is the presence of string literals that don’t have any related image identify (eg: printf("I am a anonymous string");). There are additionally padding bytes marked as *fill* within the Map file, which aren’t counted by the software as of now.

Porting To a brand new goal

When porting the software to a brand new goal, the very first thing that must be completed is to inform the software which sections map to the Textual content/Knowledge/Bss segments. This mapping is configured within the software Settings, and the data needs to be out there within the goal linker script. I’ve already configured it for FT32 and XC16. In case your goal has extra segments than the default Textual content/Knowledge/Bss, you would wish so as to add new columns into the ObjectListView and in addition create new settings for every of the brand new segments.


Instance PIC24 (XC16)

For instance take into account the reminiscence map for PIC24FJ256GB106.

/*
** Reminiscence Areas
*/
MEMORY
{
  information (a!xr) : ORIGIN = 0x800, LENGTH = 0x4000
  reset : ORIGIN = 0x0, LENGTH = 0x4
  ivt : ORIGIN = 0x4, LENGTH = 0xFC
  _reserved : ORIGIN = 0x100, LENGTH = 0x4
  aivt : ORIGIN = 0x104, LENGTH = 0xFC
  program (xr) : ORIGIN = 0x200, LENGTH = 0x2A9F8
  CONFIG3 : ORIGIN = 0x2ABFA, LENGTH = 0x2
  CONFIG2 : ORIGIN = 0x2ABFC, LENGTH = 0x2
  CONFIG1 : ORIGIN = 0x2ABFE, LENGTH = 0x2
}

The Program Flash ranges from 0x00 to 0x2AC00 (on a PIC24 program reminiscence is organized as phrases and every instruction is 24 bits vast), and accommodates the reminiscence areas reset, ivt, _reserved, aivt, program and the config phrases. Subsequent we have to discover the section to part mapping, i.e. in case you look deeper you may see that the sections [.reset, .init, .user_init, .handle, .isr, .libc, .libm, .libdsp, .lib, usercode, userconst] find yourself going into this system reminiscence which we check with as TEXT section. Equally the Knowledge (ndata, information) and BSS (nbss, bss) must be mapped. Lastly set the trail to NM and OBJDUMP – C:Program Information (x86)Microchipxc16v1.25binxc16-xxx.exe

  .reset :
  {
        SHORT(ABSOLUTE(__reset));
        SHORT(0x04);
        SHORT((ABSOLUTE(__reset) >> 16) & 0x7F);
        SHORT(0);
  } >reset
  .textual content :
  {
        *(.init);
        *(.user_init);
        KEEP (*(.deal with));
        KEEP (*(.isr*));
        *(.libc) *(.libm) *(.libdsp); /* preserve collectively on this order */
        *(.lib*);
  } >program
  usercode :
  {
        *(usercode);
  } >program

The mapping can be seen within the Map file:

Program Reminiscence  [Origin = 0x200, Length = 0x2a9f8]
part                    deal with   size (PC items)   size (bytes) (dec)
-------                    -------   -----------------   --------------------
.textual content                        0x200               0xf3a          0x16d7  (5847)
.const                      0x113a                0xb6           0x111  (273)
.dinit                      0x11f0                0xde           0x14d  (333)
.textual content                       0x12ce                0x72            0xab  (171)
                     Complete program reminiscence used (bytes):         0x19e0  (6624) 2%
Knowledge Reminiscence  [Origin = 0x800, Length = 0x4000]
part                    deal with      alignment gaps    whole size  (dec)
-------                    -------      --------------    -------------------
.ndata                       0x800                   0             0x8  (8)
.nbss                        0x808                   0             0x4  (4)
.ndata                       0x80c                   0             0x4  (4)
.nbss                        0x810                   0             0x2  (2)
.information                        0x812                   0            0xc4  (196)
.bss                         0x8d6                   0             0x6  (6)
.information                        0x8dc                   0             0x4  (4)
.bss                         0x8e0                   0             0x2  (2)
                        Complete information reminiscence used (bytes):           0xe2  (226) 1%

I’ve specified the superset of the FT32 and PIC24 mapping as default attributes in Settings.cs so all the things ought to work out of the field for FT32/PIC24. PIC32 has a extra sophisticated map, so I have not gotten round to that but.

[DefaultValue(".text, .reset, .init, .user_init, .handle, .isr, .libc, .libm, .libdsp, .lib, usercode, userconst"), Category("Segment To Section Map")]

References

  1. BINUTILS
  2. ELF Specification v1.2
  3. DWARF Specification v4
  4. Intro to DWARF Debugging Format – Michael J. Keen
  5. ASCII diagrams created utilizing JavE
  6. A significantly better record view – ObjectListView

You may additionally like… (promoted content material)

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button