Products > Embedded Computing

Getting info about chip memory layout...

(1/1)

westfw:
Is there a way to get information out of a .elf file, or out of gld, about the size of sections that exist AND the maximum size that they could be?
I know that "avr-size" will report the actual size of sections in a .elf, but I think the maximum size is long gone by then.
gld reads this info from whatever linker scripts it uses, and I'm wondering if there's some "partial" gld command that will print out information about the sections defined in the scripts actually in use, preferrably without having to do a full link of a real binary.  Maybe something like:
 
   avr-ld -T obscureLinkerScript.ld --report-section-info
 
The immediate need is to see how much space is left for .data, after obscure linker scripts have reserved an undocumented amount for use by os/libraries (on an ESP32, which apparently has a chunk of ROM-used memory in the middle of RAM, causing the .data/.bss space actually available to programs to be much less than you'd think.  Background: https://forum.arduino.cc/index.php?topic=677962.msg4566425#msg4566425 )  All defined in the linker scripts (but finding and reading linker scripts is hard!)



This would be sort-of logically similar to  "gcc options -dM -E - < /dev/null" (which shows symbols pre-defined by the compiler before it gets to any source #includes)

 
 

T3sl4co1l:
This one may be helpful,


--- Code: --->avr-objdump -h Project.elf

Project.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00001664  00000000  00000000  000000b4  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000016  00802000  00001664  00001718  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          000000e6  00802016  00802016  0000172e  2**0
                  ALLOC
  3 .fuse         00000006  00820000  00820000  0000172e  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  4 .comment      00000011  00000000  00000000  00001734  2**0
                  CONTENTS, READONLY
  5 .note.gnu.avr.deviceinfo 00000040  00000000  00000000  00001748  2**2
                  CONTENTS, READONLY
  6 .debug_aranges 000000c0  00000000  00000000  00001788  2**3
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_info   0000224c  00000000  00000000  00001848  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_abbrev 0000201a  00000000  00000000  00003a94  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_line   00000347  00000000  00000000  00005aae  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_str    000016a4  00000000  00000000  00005df5  2**0
                  CONTENTS, READONLY, DEBUGGING

--- End code ---

But I suppose, also depending on the linker scripts, maybe it's flat, nothing at all, and there won't be anything to glean from this?

I think any objdump handles any ELF format so it should be fine, I just happen to have AVR dev handy.

Tim

westfw:
(there are all sorts of utilities that show the CURRENT size of things; the space actually allocated.   What is proving difficult to find is accurate info on AVAILABLE space.  Even for the cases where there IS such info in the linker scripts.  (AVR linker scripts seem to frequently have lies, and check with "external info" post-link.  ESP32 seems to have good numbers, but I don't see them making it to the .elf files as symbols.)  (xxx-readelf seems to dump a superset of the info from xxx-nm and xxx-size and such.))

Navigation

[0] Message Index