Emit DWARF debug_abbrev offset for compile units as a label instead of 0 (#19794)
commit87ef5557017a8d822ae31587846a54fcd66daf1b
authormonojenkins <jo.shields+jenkins@xamarin.com>
Tue, 26 May 2020 16:44:37 +0000 (26 12:44 -0400)
committerGitHub <noreply@github.com>
Tue, 26 May 2020 16:44:37 +0000 (26 18:44 +0200)
tree873daed6b2b2e1a9effade6d13f6f901726fa448
parent8c085a99b32e99ae2f0a6b3de61541fefb4d3389
Emit DWARF debug_abbrev offset for compile units as a label instead of 0 (#19794)

When outputting DWARF code to start a compilation unit in .debug_info, the standard expect a 4-byte offset from the .debug_abbrev code. Mono has always output an offset of 0.

However, this doesn't work in every cases. When we have linux+fullaot, we link two object files (one from Mono, one from LLVM). Both have their .debug_abbrev section. If we use 0 as an offset, it seems possible that the linker will keep thinking that our offset is 0, no matter the circumstances. Since the offset is always 0, it can be using the wrong abbreviation table (i.e. the one from the LLVM assembly instead of the one from the Mono assembly). The consequence of this is that the linked file is not valid DWARF (dwarfdump and objdump will complain about invalid offsets). At best, some tools will be able to work with a part of what we have, but any program requiring entirely valid DWARF will fail.

To fix this, we generate a label for the start of our debug_abbrev section and we instead generate it by generating a long with that label. This matches existing behavior seen in the LLVM generated code, and makes dwarfdump and objdump react properly to the linked product.

Fixes https://github.com/mono/mono/issues/8806

Co-authored-by: Mathieu Bourgeois <mathieu.bourgeois@gameloft.com>
mono/mini/dwarfwriter.c
mono/mini/image-writer.c
mono/mini/image-writer.h