Linker scripts: strategies for debugging?

Question

I'm trying to debug a linker problem that I have, when writing a kernel.

The issue is that I have a variable SCAN_CODE_MAPPING that I'm not able to use -- it appears to be empty or something. I can fix this by changing the way I link my program, but I don't know why.

When I look inside the generated binary file using objdump, the data for the variable is definitely there, so there's just something broken with the reference to it.

Here's a gist with both of the linker scripts and the part of the symbol table that's different between the two files.

What confuses me is that both of the symbol tables have all the same symbols, they're all the same length, and they appear to contain the right data. The only difference that I can see is that they're not in the same order.

So far I've tried

• inspecting the SCAN_CODE_MAPPING memory location to make sure it has the data I expect and hasn't been zeroed out
• checking that all the symbols are the same
• checking that all the symbol contents are the same length
• looking at .data.rel.ro.local to make sure it has the address of the data

One possible clue is this warning:

warning: uninitialized space declared in non-BSS section `.text': zeroing

which I get in both the broken and the correct case.

What should I try next?

Answer 1

The problem here turned out to be that I was writing an OS, and only 12k of it was being loaded instead of the whole thing. So the linker script was actually working fine.

The main tools I used to understand binaries were:

• nm
• objdump
• readelf