Potential Debug information corruption in the example\minimal object file

[djipi]

Using the Calypsi 4.4 example\minimal project to check the object file content.

Used dwarfdump and readelf tools to check/dump the object file and tools reported error in the obj.

By example, dwarfdump --check-all reported:
"ERROR: Failure reading CU header or DIE, corrupt DWARF: DW_DLE_RELOC_SECTION_RELOC_TARGET_SIZE_UNKNOWN (233) so doing a relocation is unsafe. Attempting to continue."

[hth313]

I have no idea what the problem is here. The CU (compilation unit) record in DWARF does not appear to have any attribute that talks about relocations or sizes of such.

As far as I understand, a relocation is a mechanism to change a value in the output file based on placement of sections. It is a concern for the object file format (ELF in this case) and is not something that belongs to DWARF. Relocations can alter values (addresses) in DWARF sections as needed, but that is a mechanism related to ELF and the linker. Debug information (DWARF sections) are mostly passed through with minimal processing in the linker for performance and is intended for consumption in the debugger (if program is loaded in a debugger).

For some operating systems lacking virtual memory relocations can also be applied at load time, examples are AmigaOS, TOS and (I believe) Apple IIgs.

Is it possible to find further details on what the problem is here?

[djipi]

I do not have much to add at the moment.
I just used the project found in Calypsi-68k-4.4\example\minimal, and I wanted to have a look at the ELF/DWARF information.
I used dwarfdump and readelf tools, which are commons tools to read obj files.

I use a 68000 based platform, without Operating System.

[djipi]

I'm using the new Calypsi 5.7 toolchain for 68000, and still have difficulties to read the DWARF information in the provided example found with the toolchain. calypsi-68000-5.7\example\minimal

What tool do you use to verify an object file from compilation and/or the elf file generated by the Calypsi's linker?

[hth313]

The tools I have used is objdump.

This is a rather deep rabbit hole. DWARF is a format, not a strict standard. They encourage extensions and working with it as a basis rather than enforcing how it should be done. The reason probably being to make it more generally useful than something that gets in people's way.

I wonder what the goal is here, do you want to use a debugger? In that case it is provided with the toolchain.

[djipi]

I have integrated a UI debugger in my Atari Jaguar (68000 cpu) emulator; currently supporting DWARF 2 support, my goal is to support DWARF 5 too. The debugger features can display call stack, local variables, to trace at source code level, among others stuffs. I'm using the libdwarf library which is widely used by developers (for what I know).

For test, I'm using the example\minimal project provided with the Calypsi's toolchain.

Using a GNU objdump, such as m68k-elf-objdump.
m68k-elf-objdump -g main.o
I got various messages such as:

• Warning: Unrecognized form: 0x23
• The .debug_rnglists section contains unsupported offset entry count: 2.

With GNU readelf, such as m68k-elf-readelf, on the main.elf; this tool report corrupt table in the .debug_line section by example.

[hth313]

Getting all that to work would be work I am not able to commit to at this point. What would have to be done is debugging the reader and figure out what is actually wrong. The error messages only says that it is not happy.

The only way I managed to implement DWARF was that the family went away for a month so I got a whole month of quiet focus time to work on it. This was some years ago. I do not have that luxury these days, sadly.

[djipi]

Sure, I understand and thank you for your work too.
We can simply keep this issue open, and will try to add information in the future.