Opened 11 years ago
Closed 2 years ago
#7833 closed feature request (fixed)
CONFIGURE: Support new style DWARF2 debug info for i386 assembly
|Reported by:||SF/chkr||Owned by:||sev-|
I'm one of scummvm's packagers for Fedora. During the latest update we have stumbled over the following issue:
scummvm version: all versions, including git trunk platform: x86 and x86_64 compiler: any version of nasm (problem is only related to *.asm files)
The nasm compiler generates by default the old style "STABS" debug info:
readelf -S scummvm-1.3.1/graphics/scaler/hq3x_i386.o [...]  .stab PROGBITS 00000000 0288f0 004fec 0c 11 0 4  .stabstr STRTAB 00000000 02d8e0 00001f 00 0 0 4 [...]
This old format is not supported by the debuginfo packages generated in Fedora. As a consequence the debug information are missing for all assembler files. Although it is possible to change the debug info generated by nasm with "-F dwarf" to more recent "DWARF" type (indicated by the .debug* sections in the ELF binary):
readelf -S scummvm-1.4.0/graphics/scaler/hq3x_i386.o |grep debug [...]  .debug_info PROGBITS 00000000 028b10 00004f 00 0 0 1 [...]
that's not sufficient. The debug symbols generate by nasm are still not optimal since the DW_AT_comp_dir entry is missing:
readelf --debug-dump=info hq3x_i386.o [...] Contents of the .debug_info section: [...] <18> DW_AT_name : graphics/scaler/hq3x_i386.asm <36> DW_AT_producer : NASM 2.09.08 [...]
Most other compilers will generate debug sections like this:
readelf --debug-dump=info aspect.o [...] <11> DW_AT_name : (indirect string, offset: 0x57a): graphics/scaler/aspect.cpp <15> DW_AT_comp_dir : (indirect string, offset: 0x5f5): /home/chkr/Projects/fedora/scummvm/scummvm-1.4.0 [...]
As a result, the debuginfo packages in Fedora would not contain the assembler source files.
One possible solution would be to use the yasm assembler. If I use yasm with "-f elf32 -g dwarf2" to compile scummvm, complete and usable debug symbols are generated for the *.asm source files and full source-level debugging is possible.
Since it would be also helpful for bug reporting (complete stack traces etc.) it would be great if the problem of the wrong or incomplete debug symbols for assembler files could be fixed.
I can think of the following solutions:
a) scummvm could move entirely from nasm to yasm and add the appropriate compile flags b) the used assembler could be selected via configure script
I would be happy to provide a patch for this, please let me know how you would like to approach the issue.
Ticket imported from: #3439302. Ticket imported from: feature-requests/649.
Change History (9)
comment:1 by , 11 years ago
|Summary:||wrong debug format generated for *.asm files → Debug info for *.asm files is not compatible with Fedora|
comment:2 by , 11 years ago
comment:3 by , 11 years ago
|Summary:||Debug info for *.asm files is not compatible with Fedora → Support new style DWARF2 debug info for i386 assembly|
comment:4 by , 11 years ago
comment:5 by , 11 years ago
I think we could still go for it. My proposed approach is use yasm when it is avao;able, but fallback to nasm otherwise. Detect it at configure stage.
Christian, your patch is welcome.
comment:6 by , 5 years ago
yasm-support is already available and was added to
configure in commit 09a54d765f96c1d6eed8fdbbc42aa3b47fa8f331. However, as it is now, it's only used as fallback to
It appears that all that is needed is to reverse priority, prefer
nasm and add the appropriate switches in the
yasm-case as described by OP which should be a fairly trivial change.
comment:7 by , 5 years ago
|Summary:||Support new style DWARF2 debug info for i386 assembly → CONFIGURE: Support new style DWARF2 debug info for i386 assembly|
comment:8 by , 4 years ago
comment:9 by , 2 years ago
|Status:||new → closed|
Closing it, as it is now possible to use yasm.
Moving this to feature requests since its not really a bug.
I guess this boils down to use YASM instead of NASM for the i386 HQ scaler implementation to have better debugging information.
Personally I think the benefit is rather small, the implementation should rather be well tested by now.