DW_DLE_RNGLISTS_ERROR with dwarf 5 debug fission generated by gcc 10

[jeremy-rifkin]

Hi,
I'm seeing errors along the following lines from libdwarf and dwarfdump:

DW_DLE_RNGLISTS_ERROR: rnglists table index of 26 is unusable, there is no default  rnglists base address .

This was after compiling a test executable with gcc 10, dwarf 5, debug fission, and release mode. Interestingly I didn't encounter errors on a binary built in debug mode, I'm not sure if this is a fluke or a hint about what gcc is doing. I also didn't encounter this when building with newer versions of gcc.

I invoked dwarfdump with libdwarf-code/build/src/bin/dwarfdump/dwarfdump -i -M -G -vv --file-tied=demo test/CMakeFiles/demo.dir/demo.cpp.dwo.

Here are the relevant demo and demo.cpp.dwo files: demo_and_dwo.zip

[davea42]

I have the files and hope to take a look today.

[davea42]

Test setup works, reproduced the error.

[davea42]

I had to a little renaming (internals) to make this rnglists/loclists understandable in the code.
So, now I realize I did not write the code needed (for rnglists and loclists)
to get their data from the appropriate skeleton in the tied-file (using a signature).
We do it for .debug_addr, but not for rnglists/loclists.
So I have a bit of code to write ... not much, but some.

As is, the code only works if the rnglists/loclists are in the main object, not the tied-file.

[davea42]

Code fixed, running regression tests now.

[davea42]

I pused the fixes to github, closing the issue.

[jeremy-rifkin]

Thank you!
It looks like with the current main of libdwarf some other of my test cases are failing for me, e.g.

| compiler   | stdlib    | sanitizers | build_type     | shared | has_dl_find_object | split_dwarf | dwarf_version |
| g++-10     | libstdc++ | OFF        | RelWithDebInfo | OFF    | OFF                | ON          | 4             |

I'll look into this tomorrow to see if I'm doing something wrong of if the problem is on libdwarf's side.

[davea42]

I just fixed a problem with reading .debug_names, hope to push fix today.
See issue #261

[jeremy-rifkin]

Looks like I'm still seeing errors in 1038e7c, not sure if that's the pushed fix for 261 you refer to or not. I can look into this more later.