Some questions about lld with gdb-index option

Hi all,
    I am using below command to generate my object file named `myelf`:
    `clang++-10 -Wl,--dynamic-linker,/lib64/ld-linux-x86-64.so.2 -fuse-ld=/.../usr/bin/ld.lld -rdynamic -Wl,—gdb-index -o myelf xxx.a xxx.a xxx.a`
    I found when link with -gdb-index option, it will generate the section of .gdb_index in my elf file named myelf. But this gdb_index section is not full, and when I gdb myelf to print some function like `abc` , it shows that no symbol found(.gdb_index section donot have the function abc, but .debug_full and .symtab has this function).
    But When I am using clang++ compile without gdb-index option and then using `gdb-add-index myelf `command to add gdb-index section, this section is much larger, and When I gdb to print some function, all the symbols can be found.
    I do not understand, why lld generate a smaller .gdb_index section, and is there any options to let me generate full .gdb_index section?

    Waiting for some advices.

Best wishes.
hexiaoting
2020.2.25

I think the gdb-index support in lld only works with debug_gnu_pubnames in the input files - so you would need to compile with -ggnu-pubnames.

Maybe lld could/should have a warning or something if the input files have debug_* sections but don’t have debug_gnu_pubnames when -Wl,–gdb-index is specified.

It’s very common for some input files to have gnu-pubnames, and some not. So the warning would have to be somewhat smart.

It's very common for some input files to have gnu-pubnames, and some not.
So the warning would have to be somewhat smart.

I agree with Sterling that this can be very common:

* system libraries compiled with -g but not -ggnu-pubnames
* third-party libraries compiled with -g but not -ggnu-pubnames

I think the gdb-index support in lld only works with debug_gnu_pubnames in
the input files - so you would need to compile with -ggnu-pubnames.

Maybe lld could/should have a warning or something if the input files have
debug_* sections but don't have debug_gnu_pubnames when -Wl,--gdb-index is
specified.

The issue is https://bugs.llvm.org/show_bug.cgi?id=34820
We were hesistant on whether ld.lld should learn more DWARF stuff.

The problem is not that serious because it (`p &something` => $address, no debug
info`) only affects objfiles which haven't been parsed by gdb (something like a
lazy mode in gdb). Once an objfile is loaded, everything works fine.

Below are something not related to the topic:

Hi all,
    I am using below command to generate my object file named `myelf`:
    `clang++-10 -Wl,--dynamic-linker,/lib64/ld-linux-x86-64.so.2 -fuse-ld=/.../usr/bin/ld.lld -rdynamic -Wl,—gdb-index -o myelf xxx.a xxx.a xxx.a`

-fuse-ld=/absolute/path or -fuse-ld=relative/path is not recommended.
You'll get a warning with -Wextra.

(
The reason is that many toolchains do hacky find(path, "lld") style string match to know whether the linker is ld.lld and do something magic.
)

Use --ld-path=/path/to/ld.lld

Linking a bunch of .a files without an .o may not do what you want.
If .a does not defined a symbol which is previously undefined, the .a file will be dropped from the link.

Options (LD) "-l namespec" and
https://lld.llvm.org/ELF/warn_backrefs.html
have some information.

    I found when link with -gdb-index option, it will generate the section of .gdb_index in my elf file named myelf. But this gdb_index section is not full, and when I gdb myelf to print some function like `abc` , it shows that no symbol found(.gdb_index section donot have the function abc, but .debug_full and .symtab has this function).

The two-dash form --gdb-index is recommended.

It’s very common for some input files to have gnu-pubnames, and some not.
So the warning would have to be somewhat smart.

I agree with Sterling that this can be very common:

  • system libraries compiled with -g but not -ggnu-pubnames
  • third-party libraries compiled with -g but not -ggnu-pubnames

Sure, but the resultant broken gdb behavior is pretty problematic to experience without some notification.

If gdb-index had a way to say which CUs it covers (.debug_names has this, I believe), that’d be great - but without that, I think it’s fundamentally invalid/incorrect to produce an incomplete gdb-index.

I think the gdb-index support in lld only works with debug_gnu_pubnames in
the input files - so you would need to compile with -ggnu-pubnames.

Maybe lld could/should have a warning or something if the input files have
debug_* sections but don’t have debug_gnu_pubnames when -Wl,–gdb-index is
specified.

The issue is https://bugs.llvm.org/show_bug.cgi?id=34820
We were hesistant on whether ld.lld should learn more DWARF stuff.

I think it should be: either create a complete gdb-index, or error. Creating an incomplete gdb-index is/should be considered a fairly severe bug.

The problem is not that serious because it (p &something => $address, no debug
info`) only affects objfiles which haven’t been parsed by gdb (something like a
lazy mode in gdb). Once an objfile is loaded, everything works fine.

I’d say this is pretty serious - unreliable operations lead to lack of confidence/pretty deep frustration with tools.

Worth noting that both gnu gold and gnu ld parse the debug info and generate entries for missing files. It is slower than one might want, but with --gdb-index on the command line, it seems like one would be willing to pay that cost.