[llvm-dev] Some questions about lld with gdb-index option

[何文婷 via llvm-dev]

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

 

[David Blaikie via llvm-dev]

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.

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Sterling Augustine via llvm-dev]

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

[Fangrui Song via llvm-dev]

On 2021-02-27, Sterling Augustine wrote:
>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

>On Sat, Feb 27, 2021 at 2:48 PM David Blaikie via llvm-dev <
>llvm...@lists.llvm.org> wrote:
>
>> 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:

>> On Sat, Feb 27, 2021 at 9:52 AM 何文婷 via llvm-dev <llvm...@lists.llvm.org>
>> wrote:
>>
>>> 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.

https://sourceware.org/binutils/docs/ld/Options.html "-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.

[David Blaikie via llvm-dev]

On Sat, Feb 27, 2021 at 6:20 PM Fangrui Song <mas...@google.com> wrote:

On 2021-02-27, Sterling Augustine wrote:
>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.
 

>On Sat, Feb 27, 2021 at 2:48 PM David Blaikie via llvm-dev <
>llvm...@lists.llvm.org> wrote:
>
>> 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.

[Sterling Augustine via llvm-dev]

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.