Closed damageboy closed 3 years ago
Thanks! It seems that there are 2 issues:
For 1, that should be an easy fix. Need to investigate 2.
I have tried to fix both issues by commit c678e7c8a59623c2b250be28c19b91b22023cfb6 but I will have to push more tests later.
In the meantime, can you try with latest master to check if it is fixing your issue?
So with the new system, you can output multiple line program table and you should be able to create 2 compilation units associated with 2 different line program table.
It seems that multiple line sequences within a line program table is actually not generated by gcc. Otherwise, one compilation unit is associated with one line program table. Note also that you might need to generate also a .symtab for the functions in your ELF.
Thanks @xoofx, I'll give it a go in a couple of hours and report right back!
Looking good!
I've tested the multiple line-sequences in on table so far, and the previous warning no longer appears.
This is good enough for objdump
for now.
I will also re-write the code to output one linetable per file, which is what gcc/clang -shared
produce for me, and will report back.
If all is good I'll close the issue. Thanks for everything!
Hi, I'm trying to generate an object file with multiple source file worth of debug information as part of an effort to make JitDasm support dumping JIT results all the way down to ELF.
As such, I want to provide multiple line sequences in one object file. LibObjectFile's current API does allow for this, as can be seen from my code here: https://github.com/damageboy/JitDasm/blob/wip/dumptoelf/JitDasm/ElfDumper.cs#L155
The resulting object file seems to provide a partially working result, but the various elf dumping utilities seem to complain about the length field:
readelf -W --debug-dump=rawline /tmp/x.o
:As you can see the warning is:
Other tools complain about the same thing (
objdump
) or crash (llvm-dwarfdump
).I'm not familiar enough with DWARF to say with any certainty that this form of serializing is "legal" to begin with (e.g. one filename table with multiple entries and multiple sequences).
I will mention that while researching I found out that when compiling a shared object with multiple source files with gcc/clang, the resulting
.debug_line
section that is produced is entirely different when compared to LibObjectFile, where multiple tables appear in succession, in theory, one per file in succession:I don't know if this last bit is even important, as I don't happen to think that the current layout used by LibObjectFile is wrong in any way, I'm just mentioning this for completeness sake.