GNU ld question

[bzt]

I have a really simple question. The elf documentation states:

.strtab
Strings, most commonly the strings that represent the names associated with symbol table entries. If the file has a loadable segment that includes the symbol string table, the section's attributes will include the SHF_ALLOC bit. Otherwise, that bit will be turned off.

.symtab
Symbol table, as "Symbol Table" describes. If the file has a loadable segment that includes the symbol table, the section's attributes will include the SHF_ALLOC bit. Otherwise, that bit will be turned off.

So my question is, how to do that? How to tell ld to include those sections in a loadable segment? The documentation neglect to tell that little detail...

I can control any other sections, but not these, because ld simply ignores my rules (so does objdump ignore these sections). I've tried all variations I could think of, I've googled a lot but nothing. I've also checked command line options and maybe if PHDRS command has some magic keyword for it, but nothing. Here's my linker script that I think should work:

Code: Select all

    .text CORE_ADDRESS + SIZEOF_HEADERS + (8192): AT(ADDR(.text) - CORE_ADDRESS + SIZEOF_HEADERS)
    {
           ...
        *(.text)
        *(.symtab)
        *(.strtab)
           ...
    } :text

And the output:

Code: Select all

Section Headers:
     ....
  [10] .symtab           SYMTAB           0000000000000000  000224a8
       0000000000001bf0  0000000000000018          11    96     8
  [11] .strtab           STRTAB           0000000000000000  00024098
       0000000000000b9c  0000000000000000           0     0     1

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0xffffffffffe02000 0x0000000000002078
                 0x0000000000018140 0x0000000000018140  RWE    80

 Section to Segment mapping:
  Segment Sections...
   00     .text .got.plt

As you can see, LOAD segment ends at 18140, and symbol table starts at 24098 and not listed in segment mapping.

Please somebody restore my faith in GNU software...

[bzt]

Nobody?

[alexfru]

Compile and link with something like -g option?

[bzt]

Compile and link with something like -g option?

Thank you for your answer!

Actually it makes the situation even worse, as -g puts some more sections between the text section and the symtab, so the symbol table gets further away from the loadable segment

It's not nice at all, but I've workarounded by loading the entire file instead of the segment and adding ". += 4096" before the bss_start in linker script.

[cyr1x]

Add a DYNAMIC program header like this:

Code: Select all

PHDRS
{
    text PT_LOAD FLAGS(5);
...
    dynamic PT_DYNAMIC;
}

The symbol and string tables will be located therein.

[alexfru]

Compile and link with something like -g option?

Thank you for your answer!

Actually it makes the situation even worse, as -g puts some more sections between the text section and the symtab, so the symbol table gets further away from the loadable segment

It's not nice at all, but I've workarounded by loading the entire file instead of the segment and adding ". += 4096" before the bss_start in linker script.

I think the symbol and string sections, even if they're loadable, should (or can be made to) work at any location.

[xenos]

I don't know about .symtab and .strtab (I haven't tried with those so far), but if you have a dynamic object / shared library, then the .dynsym and .dynstr sections can definitely be placed in loadable segments. If you have exported symbols that you want to access, they will be in these sections anyway, so these would be the ones you need. I guess this is also what cyr1x was referring to. Have a look at my linker script, this is how it works in my kernel:

https://github.com/xenos1984/NOS/blob/m ... script#L60

[bzt]

Add a DYNAMIC program header like this:

Code: Select all

PHDRS
{
    text PT_LOAD FLAGS(5);
...
    dynamic PT_DYNAMIC;
}

The symbol and string tables will be located therein.

Good thinking, already tried that, but my dynamic section is empty:

Code: Select all

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0xffffffffffe02000 0x00000000000000b0
                 0x0000000000019000 0x0000000000019000  R E    80
  DYNAMIC        0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000         8

Doesn't matter whether I add the following to linker script or not

Code: Select all

    .dynamic : { *(.dynamic) } :text :dynamic

After a long google session it turned out it's a bug in ld that came in somewhere around 2.23 and still exists in my version 2.27
http://stackoverflow.com/questions/2929 ... mbol-table
But I appreciate it, it was a good advice btw.

[bzt]

I think the symbol and string sections, even if they're loadable, should (or can be made to) work at any location.

You are absolutely right. My problem was:
1. the symbol table is not in the loadable segment, so it was not loaded into memory in the first place
2. even when I modified my loader to load the entire file, the address of symbol table is above __bss_start, so it's got overwritten as soon as I initialize pmm.

[alexfru]

I think the symbol and string sections, even if they're loadable, should (or can be made to) work at any location.

You are absolutely right. My problem was:
1. the symbol table is not in the loadable segment, so it was not loaded into memory in the first place
2. even when I modified my loader to load the entire file, the address of symbol table is above __bss_start, so it's got overwritten as soon as I initialize pmm.

If the symbol and string tables aren't loadable (as is the case in object files prior to linking), they clearly don't have any designated location and any should do. They are not essential for execution. Look up the ELF spec. The symbol/string info is tied to sections in relative terms (section index, offset within section and so on). Where this info is located itself doesn't matter.

[cyr1x]

I don't know about .symtab and .strtab (I haven't tried with those so far), but if you have a dynamic object / shared library, then the .dynsym and .dynstr sections can definitely be placed in loadable segments. If you have exported symbols that you want to access, they will be in these sections anyway, so these would be the ones you need. I guess this is also what cyr1x was referring to.

You are absolutely right. Now I remember this was the exact same problem I faced. Switching to .dynsym and .dynstr fixed it for me.

[bzt]

I don't know about .symtab and .strtab (I haven't tried with those so far), but if you have a dynamic object / shared library, then the .dynsym and .dynstr sections can definitely be placed in loadable segments. If you have exported symbols that you want to access, they will be in these sections anyway, so these would be the ones you need. I guess this is also what cyr1x was referring to. Have a look at my linker script, this is how it works in my kernel:

https://github.com/xenos1984/NOS/blob/m ... script#L60

Thanks, I've tried that, but my kernel is not a shared library. Maybe that's the reason why my dynamic section is empty? Anyway I managed to create a workaround

About .symtab and .strtab: they are exactly the same as .dynsym and .dynstr, only it's not in loader's view (phdr) but in linker's view (shdr). For debugging it's better as .symtab has all the symbols, not just the exported public ones. I've wrote an wiki page on how to find them.