llvm dev - Aug 2010 - [LLVMdev] [cfe-dev] Debug information on multiple files

Hi,

I'm trying to compile two files together with debug information but
seems that LLVM is getting the DW_AT_stmt_list wrong when ld is
linking the final executable.

Originally, I tried on ARM with Clang (+llc+gas+ln) and, the object
files, the DW_AT_stmt_list were null, as expected. When linking, they
should point to the offset in the line table, but all of them are
still null, so pointing all to the same line table (whichever object
gets linked first).

I then tested with SVN Clang+LLVM and got the same problem for x86-64.
In GDB, when you're stepping through the program, whichever file got
linked first has line information and you can only step on the source
of the first object.

My Files:

-------------------------------- ext.c
#include <stdio.h>

int external_fn(void)
{
  int i;
  for (i = 0; i < 5; ++i) {
    printf("ext fn #%d\n", i);
  }
  return 0;
}

-------------------------------- main.c
#include <stdio.h>

int external_fn(void);

int main(int argc, char** argv)
{
  printf("TestMsg\n");
  external_fn();
  return 0;
}

$ clang -g main.c ext.c
$ gdb -q a.out
(gdb) start
Temporary breakpoint 1 at 0x4004c0: file main.c, line 7.
Starting program: /work/temp/a.out

Temporary breakpoint 1, main (argc=1, argv=0x7fffffffbf18) at main.c:7
7         printf("TestMsg\n");
(gdb) n
TestMsg
8         external_fn();
(gdb) s
ext fn #0
ext fn #1
ext fn #2
ext fn #3
ext fn #4
9         return 0;
(gdb)

If I compile ext.c first, main has no line information:

$ clang -g ext.c main.c
$ gdb a.out
(gdb) start
Temporary breakpoint 1 at 0x4004e4
Starting program: /work/temp/a.out

Temporary breakpoint 1, 0x00000000004004e4 in main (argc=0, argv=0x7fffffffbf10)
(gdb) n
Single stepping until exit from function main,
which has no line number information.
TestMsg
ext fn #0
ext fn #1
ext fn #2
ext fn #3
ext fn #4
0x00000033c5e1d974 in __libc_start_main () from /lib64/libc.so.6
(gdb)


What am I missing?

-- 
cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

See "DwarfDebug problem with line section" thread on llvmdev. Bottom
line,
we may need a target specific patch for targets that do not follow dwarf
standard (as per my reading) in this particular case.
-
Devang


On Wed, Aug 25, 2010 at 5:49 AM, Renato Golin <rengolin at
systemcall.org>wrote:
> Hi,
>
> I'm trying to compile two files together with debug information but
> seems that LLVM is getting the DW_AT_stmt_list wrong when ld is
> linking the final executable.
>
> Originally, I tried on ARM with Clang (+llc+gas+ln) and, the object
> files, the DW_AT_stmt_list were null, as expected. When linking, they
> should point to the offset in the line table, but all of them are
> still null, so pointing all to the same line table (whichever object
> gets linked first).
>
> I then tested with SVN Clang+LLVM and got the same problem for x86-64.
> In GDB, when you're stepping through the program, whichever file got
> linked first has line information and you can only step on the source
> of the first object.
>
> My Files:
>
> -------------------------------- ext.c
> #include <stdio.h>
>
> int external_fn(void)
> {
>  int i;
>  for (i = 0; i < 5; ++i) {
>    printf("ext fn #%d\n", i);
>  }
>  return 0;
> }
>
> -------------------------------- main.c
> #include <stdio.h>
>
> int external_fn(void);
>
> int main(int argc, char** argv)
> {
>  printf("TestMsg\n");
>  external_fn();
>  return 0;
> }
>
> $ clang -g main.c ext.c
> $ gdb -q a.out
> (gdb) start
> Temporary breakpoint 1 at 0x4004c0: file main.c, line 7.
> Starting program: /work/temp/a.out
>
> Temporary breakpoint 1, main (argc=1, argv=0x7fffffffbf18) at main.c:7
> 7         printf("TestMsg\n");
> (gdb) n
> TestMsg
> 8         external_fn();
> (gdb) s
> ext fn #0
> ext fn #1
> ext fn #2
> ext fn #3
> ext fn #4
> 9         return 0;
> (gdb)
>
> If I compile ext.c first, main has no line information:
>
> $ clang -g ext.c main.c
> $ gdb a.out
> (gdb) start
> Temporary breakpoint 1 at 0x4004e4
> Starting program: /work/temp/a.out
>
> Temporary breakpoint 1, 0x00000000004004e4 in main (argc=0,
> argv=0x7fffffffbf10)
> (gdb) n
> Single stepping until exit from function main,
> which has no line number information.
> TestMsg
> ext fn #0
> ext fn #1
> ext fn #2
> ext fn #3
> ext fn #4
> 0x00000033c5e1d974 in __libc_start_main () from /lib64/libc.so.6
> (gdb)
>
>
> What am I missing?
>
> --
> cheers,
> --renato
>
> http://systemcall.org/
>
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


-- 
-
Devang
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100825/7a55f374/attachment.html>

On 25 August 2010 18:54, Devang Patel <devang.patel at gmail.com>
wrote:
> See "DwarfDebug problem with line section" thread on llvmdev.
Bottom line,
> we may need a target specific patch for targets that do not follow dwarf
> standard (as per my reading) in this particular case.
Hi Devang,

Ok, got the background, but will reply on this email.

As far as I understood, there is nothing wrong with the way clang
deals with stmt_list. The encoding is correct (AFAIK) and the offsets
are always zero in every object file, as there is only one line table
and one debug_info. The problem is during link time. GCC also
generated zero for stmt_list in the objects but links correctly in the
end.

I still haven't figured out which type of relocation is needed. All I
know is that GCC generates .rel.debug_info relocations that clang
doesn't:

clang:

** Section #6 '.rel.debug_info' (SHT_REL)
    Size   : 40 bytes (alignment 4)
    Symbol table #22 '.symtab'
    5 relocations applied to section #5 '.debug_info'

GCC:

** Section #7 '.rel.debug_info' (SHT_REL)
    Size   : 184 bytes (alignment 4)
    Symbol table #22 '.symtab'
    23 relocations applied to section #6 '.debug_info'

I'll dig deeper and see if I can spot what should be done.

cheers,
--renato