Open nagisa opened 6 years ago
The usual addresses are something like 0x40_0000
and up, whereas "RAM" sections are placed at addresses in the 0x2000_0000
range.
Is this for ELF or Mach-O?
It would be really helpful to see the listing of sections and segments from the binary.
ELF. The following listing has the sections present in the binary. Are segments something else?
file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 A6 rw 0000208f 00400000 00400000 00000278 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 A0 rw 00000148 00404000 00404000 00002308 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 P1 ro 00001db0 00404148 00404148 00002450 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 A2 rw 00000004 00405efc 00405efc 00004200 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 P1 ro_2 00000100 00405f00 00405f00 00004204 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 A4 rw 00000004 00406000 00406000 00004304 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 P1 ro_3 00011b98 00406004 00406004 0000430c 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
7 A3 rw 0000000c 00417ba0 00417ba0 00015ea4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 P1 ro_4 00031078 00417bac 00417bac 00015eb0 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
9 A1 rw 00000008 00448c28 00448c28 00046f28 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 P1 ro_5 00016d94 00448c30 00448c30 00046f30 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 A5 rw 00000004 0045fffc 0045fffc 0005dcc4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 A7 rw 0000f70c 00460000 00460000 0005dcc8 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
13 A8 rw 0000f70c 00470000 00470000 0006d3d8 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
14 P2 rw 00000f02 20004900 20004900 00000000 2**3
ALLOC, CODE
15 P2 zi 0001c370 20005804 20005804 00000000 2**3
ALLOC, CODE
16 P2 ui 00003000 20021b78 20021b78 00000000 2**3
ALLOC
17 .iar.debug_frame 00007ac4 00000000 00000000 0007d128 2**0
CONTENTS, READONLY
18 .iar.debug_line 00067455 00000000 00000000 00084bec 2**0
CONTENTS, READONLY
19 .comment 00083ff2 00000000 00000000 000ec041 2**0
CONTENTS, READONLY
20 .iar.rtmodel 00000061 00000000 00000000 00170033 2**0
CONTENTS, READONLY
21 .ARM.attributes 0000002e 00000000 00000000 00170094 2**0
CONTENTS, READONLY
22 Fill1 00000004 00405ef8 00405ef8 0007cae4 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
23 Fill2 00000004 00417b9c 00417b9c 0007cae8 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
24 Fill3 00000004 00448c24 00448c24 0007caec 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
25 Fill4 00000638 0045f9c4 0045f9c4 0007caf0 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
To see segments, try readelf -l
.
Also what address is printed with the error message?
$ readelf -l
$ bloaty file.elf
but does not print anything else. Running verbosely seems to start working on P2 rw
before failing:
$ bloaty -vvv file.elf
I'm running into this also with an ELF file produced by Cypress PSoC Creator. It uses GCC but the final build step adds section .cyloadermeta, which seems to have the offending region.
I figured I would use objcopy to produce an ELF without it: arm-none-eabi-objcopy: fixed.elf: warning: allocated section `.cyloadermeta' not in segment
Without that section, bloaty is happy with the ELF.
If it is helpful, I can build an ELF from one of the sample projects and share that.
Trying bloaty on my IAR-compiled embedded executable yields this result.
From the
-vvv
output it seems that the issue occurs when bloaty is trying to deal with a section that is placed at the "RAM" addresses.I cannot provide a sample file (sadly), but am willing to help in investigating the issue (such as running arbitrary toolchain commands on the file and extracting information from that).