search

xinu-os / xinu

Repository for Xinu source code
http://xinu-os.org/
Other
430 stars 128 forks source link

Discard unknown sections otherwise they can get inserted before _start -... #3

Closed jsgh closed 5 years ago

jsgh commented 10 years ago

... ".note.gnu.build-id" being a particular problem here.

I was having problems with builds sometimes working, but often crashing immediately (either the rainbow screen or just blank). Turns out this gcc/ld version inserts a 36-byte section into the ELF file including a 16-byte header (which mostly disassembles as add/sub instructions) followed by a 20-byte hash. The linker then, not having any better instructions, inserts it first at the linker script's origin. Depending on exactly which instructions the hash represents (often invalid) this either has no visible effect or crashes before we can reach _start, or perturbs things enough that _start then fails.

ebiggers commented 10 years ago

Thanks for reporting this. That's some pretty silly default behavior by ld...! I've committed a modified form of this so that we can fix the problem on other platforms as well. Also, I decided to only discard .comment and .note sections, since there may be other sections (e.g. debug sections generated by a 'make debug' build) that aren't explicitly mentioned in the linker scripts but should still appear in the output file.

jsgh commented 10 years ago

In which case there should be an explicit * rule that places them out of the way (probably not right at the end, after bss, perhaps between .text and .rodata, or after .rodata?)

ebiggers commented 10 years ago

That would be ideal, since then no sections would be automatically placed. Problem is, if you look at which sections are in files generated from a 'make debug' build, there are a bunch of different sections like:

.mdebug.abi32 [ MIPS only? ] .ARM.attributes [ ARM only? ] .stab .stabstr .shstrtab .symtab .strtab

These do not have a consistent naming and it's not immediately clear which are actually required for debugging. I could look into this though.

jsgh commented 10 years ago

Hmm.

.stab and .stabstr are STABS format debuginfo. .shstrtab is the names of the sections themselves. .strtab is the names of program symbols. .ARM.attributes appears to contain extra description of the target CPU and ABI, which presumably can't be expressed as normal ELF format codes/flags in the file header. No idea about .mdebug.abi32 since my mips xc doesn't appear to generate it, but given the number of different mips arch variants could well be the same sort of thing.

None of which are necessary in the final binary blob (for targets not using ELF themselves), but luckily...

If you do an "objdump -h" on the files, I think only the sections flagged ALLOC+LOAD should actually make it into the final blob during objcopy, or get loaded into memory for ELF targets (all the rest should have a VMA of 0 too, since that's not actually used for them), and the only one of those that appears to be a problem here is the build-id section. .comment isn't so marked so shouldn't affect layout of the running image.