llvm dev - Oct 2010 - [LLVMdev] Possibility of Corruption of debug metadata

Hi Devang,
I convert all global variables in a file to thread local at the IR level.
i.e. compile example_llvm.c  to IR example_llvm.ll and change global
variables to thread-local variables. I also insert a function call just before
access of the global(now thread-local) variable. I also insert a local variable
in main. Does these operations in any way effect the debug metadata ?

I do not face any issues debugging my test case. But while debugging
my application
through gdb I cannot make sense of the call stack. I do not see the
function names in
the call stack (with or without insertion of additional function calls
or local variables).

On Wed, Oct 13, 2010 at 10:35 AM, Devang Patel <dpatel at apple.com>
wrote:
>
>
>
> On Oct 12, 2010, at 4:28 PM, shankha <shankhabanerjee at gmail.com>
wrote:
>
>> Hi,
>> If I convert global variables to thread-local variables or vice versa
>> at the IR stage do I have to take care of the debug metadata.
>
> If you provide an small concrete example then it would help,
>
> Devang
>> I looked at the IR generated and I couldn't find any difference
>> between the debug metadata generated for global variables and
>> thread-local variables.
>>
>> --
>> Thanks
>> Shankha
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 
Thanks
Shankha Banerjee
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example_llvm.ll
Type: application/octet-stream
Size: 4203 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101013/45270142/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example_llvm_w.ll
Type: application/octet-stream
Size: 4436 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101013/45270142/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example_llvm.c
Type: text/x-csrc
Size: 202 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101013/45270142/attachment.c>

In your example, you do not need to update debug info for @global_var at the
moment. We are not identifying tls in debug info yet.

On Oct 13, 2010, at 8:30 AM, shankha wrote:
> I do not face any issues debugging my test case. But while debugging
> my application
> through gdb I cannot make sense of the call stack. I do not see the
> function names in
> the call stack (with or without insertion of additional function calls
> or local variables).
What is the difference between your test case and application ? Is your
application compiled using same compiler options ?
-
Devang

Hi Devang,

On Wed, Oct 13, 2010 at 12:44 PM, Devang Patel <dpatel at apple.com>
wrote:
> In your example, you do not need to update debug info for @global_var at
the moment. We are not identifying tls in debug info yet.
Does that mean I will not be able to debug applications which use tls
through gdb if they are  build with gcc-lllvm or clang.
> On Oct 13, 2010, at 8:30 AM, shankha wrote:
>
>> I do not face any issues debugging my test case. But while debugging
>> my application
>> through gdb I cannot make sense of the call stack. I do not see the
>> function names in
>> the call stack (with or without insertion of additional function calls
>> or local variables).
>
> What is the difference between your test case and application ? Is your
application compiled using same compiler options ?
   My application is the linux kernel TCP/IP stack layer. There are
few #defines and compiler options which are different. Such as
 -D"KBUILD_STR(s)=#s" -D"KBUILD_MODNAME=KBUILD_STR()"
-D__KERNEL__,
-fno-common -fno-strict-aliasing.

Are these options in any way responsible for the problems I am facing
while debugging.
At this moment it is not possible for me to run my application
standalone without
modifying it.


Thanks for your help.
> -
> Devang


-- 
Thanks
Shankha Banerjee