[llvm-commits] [llvm] r119777 - in /llvm/trunk: include/llvm/MC/MCDwarf.h include/llvm/MC/MCStreamer.h include/llvm/Target/TargetMachine.h lib/CodeGen/LLVMTargetMachine.cpp lib/MC/MCAsmStreamer.cpp lib/MC/MCDwarf.cpp lib/MC/MCELFStreamer.cpp lib/

[Rafael Espíndola]

> It does not help when .loc is not used, say darwin9 :)

on llvm-gcc. Would it help if I added a debug option to llvm-gcc to use it?

>>
>>> Right now I am debugging a regression caused by related patches in .debug_line output and it is very difficult to investigate with comments in assembly output.
>>
>> There are two possibilities, the output with .loc is incorrect, in
>> which case reading the assembly and finding out that a ".loc 1 2 3"
>> should actually be ".loc 2 2 3" is not that hard.
>>
>> The assembler (MC) is wrong. In this case you should be able to
>> compare the output of llvm-mc and the system assembler.
>
> When 1) .loc is not used and 2) the code generator does not integrated assembler then the emitted .s file has wrong line table entries. I looked at the  _clz.s (from libgcc during llvm-gcc bootstrap).
>
>        .section        __DWARF,__debug_line,regular,debug
> Ltmp0:
>        .long   (Ltmp1-Ltmp0)-4
>        .short  2
>        .long   (Ltmp2-Ltmp0)-10
>        .byte   1
>        .byte   1
>        .byte   -5
>        .byte   14
>        .byte   13
>        .byte   0
>        .byte   1
>        .byte   1
>        .byte   1
>        .byte   1
>        .byte   0
>        .byte   0
>        .byte   0
>        .byte   1
>        .byte   0
>        .byte   0
>        .byte   1
>        .byte   0
>        .ascii   "libgcc2.c"
>        .byte   0
>        .byte   0
>        .byte   0
>        .byte   0
>        .ascii   "libgcc2.h"
>        .byte   0
>        .byte   0
>        .byte   0
>        .byte   0
>        .byte   0
> Ltmp2:
> Ltmp1:
>
>
> AFAICT, this line table is incomplete. Here lack of comments does not make it easier. Note, use of integrated assembler + set UseMCLoc to true, results in correct .o file. So the bug is in
>
> //
> // This emits the Dwarf file and the line tables.
> //
> void MCDwarfFileTable::Emit(MCStreamer *MCOS,
>                            const MCSection *DwarfLineSection,
>                            MCSectionData *DLS,
>                            int PointerSize) {
>
>
> This is a new code that replaced its alternative in DwarfDebug.cpp
>
> Can you take a look ? This is causing llvm-gcc-i388-darwin9 buildbot failures. You should be able to use following simple c input.
> ---
> char *c[4] = "hi\n";

So, given the hypothetical -fdwarf2-cfi-asm to llvm-gcc, the bug you
have is that

llvm-gcc -S -fdwarf2-cfi-asm t.c -o t.s && llvm-mc -filetype=obj t.s -o t-mc.o

produces different output from

llvm-gcc -S t.c -o t.s && llvm-mc -filetype=obj t.s -o t-test.o

Correct? In general the output will be different, but for a case
without pointer updates I don't see why it should be. If that is
really the bug, I can take a look. Would you mind adding something to
bugzilla?

> ---
>
> Thanks,
> -
> Devang
>
>

Cheers,
Rafael