Getting info about chip memory layout... - Page 1
Forum section: electronics / general

author: westfw
author_rank: Super Contributor
timestamp: April 19, 2020, 10:03:07 am
content: 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 inthe 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-infoThe 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 "gccoptions-dM -E - < /dev/null" (which shows symbols pre-defined by the compiler before it gets to any source #includes)

author: T3sl4co1l
author_rank: Super Contributor
timestamp: April 19, 2020, 02:04:59 pm
content: This one may be helpful,Code:>avr-objdump -h Project.elfProject.elf: file format elf32-avrSections:Idx Name Size VMA LMA File off Algn0 .text 00001664 00000000 00000000 000000b4 2**1CONTENTS, ALLOC, LOAD, READONLY, CODE1 .data 00000016 00802000 00001664 00001718 2**0CONTENTS, ALLOC, LOAD, DATA2 .bss 000000e6 00802016 00802016 0000172e 2**0ALLOC3 .fuse 00000006 00820000 00820000 0000172e 2**0CONTENTS, ALLOC, LOAD, DATA4 .comment 00000011 00000000 00000000 00001734 2**0CONTENTS, READONLY5 .note.gnu.avr.deviceinfo 00000040 00000000 00000000 00001748 2**2CONTENTS, READONLY6 .debug_aranges 000000c0 00000000 00000000 00001788 2**3CONTENTS, READONLY, DEBUGGING7 .debug_info 0000224c 00000000 00000000 00001848 2**0CONTENTS, READONLY, DEBUGGING8 .debug_abbrev 0000201a 00000000 00000000 00003a94 2**0CONTENTS, READONLY, DEBUGGING9 .debug_line 00000347 00000000 00000000 00005aae 2**0CONTENTS, READONLY, DEBUGGING10 .debug_str 000016a4 00000000 00000000 00005df5 2**0CONTENTS, READONLY, DEBUGGINGBut 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

author: westfw
author_rank: Super Contributor
timestamp: April 20, 2020, 07:38:18 am
content: (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.))