I noticed that compiling t.c with '-gdwarf-4', I get: <15> DW_AT_comp_dir : (indirect string, offset: 0x4e): /tmp But compiling t.s, I get: <24> DW_AT_comp_dir : /tmp Looking at 'as' invocation, t.c build results in: as -v --64 -o t.o /tmp/ccSXi0lI.s while t.s results in: as --gdwarf2 -v --64 -o t.o t.s Given that dwarf-4 is now the default, passing --gdwarf2 to as is the wrong thing to do, especially given -gdwarf-4 on command line. This was with trunk GCC built @r198709, native Linux/x86_64 build, configured with: --enable-linker-build-id --disable-lto --with-linker-hash-style=gnu --enable-languages=c,c++,go
Hmm, it appears that the current binutils 'as' doesn't know how to generate -gdwarf-4, so it should be fixed first. Cary?
I don't see how this is wrong. Mixing dwarf4 and dwarf2 should be ok.
(In reply to Andrew Pinski from comment #2) > I don't see how this is wrong. It's wrong to emit dwarf2 because I asked for dwarf4 explicitly. > Mixing dwarf4 and dwarf2 should be ok. Ok for what? One of the reasons I ask for dwarf4 is to save on repeated DW_AT_comp_dir strings (which could be quite long). Currently, I do get them merged for all .c and .cc compoilation units, but not for any .s units. That seems broken to me.
There's no reason to expect that -gdwarf-4 will automatically get you an indirect string here -- DW_FORM_strp was just as valid in DWARF 2 and 3 as it is in DWARF 4. Here the assembler is simply making the choice to put the string inline. I'm not sure if that's because there's no support for indirect strings at all in the assembler or because it doesn't expect the comp_dir string to be duplicated. I think what you're really asking for is to have the assembler generate indirect strings. That can be done without upgrading to DWARF 4. While I do agree that the assembler ought to be able to generate DWARF 4 by now, for the kind of debug output that the assembler generates, I don't think it's really all that important. -cary
(In reply to Cary Coutant from comment #4) > I think what you're really asking for is to have the assembler generate > indirect strings. That can be done without upgrading to DWARF 4. Yes. > While I do agree that the assembler ought to be able to generate DWARF 4 by > now, for the kind of debug output that the assembler generates, I don't > think it's really all that important. True. I've opened binutils http://sourceware.org/bugzilla/show_bug.cgi?id=15457 Closing this one.