Hi Pogo & James,<br><br>Pogo, that is exactly the kind of answer I was expecting. Thanks for the time you spend on this problem. I myself did also some experimenst and found way to get what I'm expecting but I think that at least for x86 or any parameter passed on the stack for a different architecture the way LLVM handle debug information might be a problem. So here was the situation:<br>
My front-end at -O0 generates direct access to parameters and I used llvm.dbg.value to associate metadata and I couldn't get llc to generate fp related debug info that would have made 'n' value available at first breakpoint.<br>
I eventually found looking at what's generated by clang at -O0 that I should first 'home' the parameter (make a local copy to a variable) then use llc -disable-fp-elim so that 'n' value can be inspected. My feeling is that LLVM debug info generation is based on LLVM code-style emitted by clang and might not deal when code is emitted by a different front-end.<br>
James, no need to apology we all make mistakes, including myself.<br><br>Best Regards<br>Seb <br><br><div class="gmail_quote">2012/3/9 James Molloy <span dir="ltr"><<a href="mailto:james.molloy@arm.com">james.molloy@arm.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<div class="im"><br>
> I do have to take exception to James Molloy's assessment of the variable<br>
"n"<br>
> as "optimized away" because the debug info clearly thought it wasn't.<br>
<br>
</div>Mea culpa here, I misread the original email and saw "<value optimized out>"<br>
for the wrong parameter. Then didn't recheck the original email when<br>
follow-ups happened.<br>
<br>
I apologise.<br>
<br>
Cheers,<br>
<br>
James<br>
<div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: Paul Robinson [mailto:<a href="mailto:pogo.work@gmail.com">pogo.work@gmail.com</a>]<br>
Sent: 08 March 2012 23:00<br>
To: Seb<br>
Cc: <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>; James Molloy<br>
Subject: Re: [LLVMdev] Problem with x86 32-bit debug information ?<br>
<br>
On Wed, Mar 7, 2012 at 6:50 AM, Seb <<a href="mailto:babslachem@gmail.com">babslachem@gmail.com</a>> wrote:<br>
> Hi James,<br>
><br>
> I fully agree with you and understand your statement about -O2.<br>
><br>
> Now some questions for you:<br>
> Did you try to reproduce experiments described in my previous e-mail ?<br>
> Did you look at debug informations generated for 'n' parameter on x86<br>
32-bit<br>
> & x86 64-bit ?<br>
> I'm working on my own front-end for LLVM and I had difficulties with debug<br>
> information when they are related to x86 32-bits. So far there are two<br>
> options:<br>
> 1) metadata that I generate are incorrect.<br>
> 2) LLVM is not handling in a correct manner those metadata for x86 32-bit<br>
> target.<br>
> I've already posted problem related to metadata that I generate and they<br>
are<br>
> in LLVM 2.9 format. I've been adviced to move to most recent format.<br>
Before<br>
> starting any move into that direction, I would like to be sure that LLVM<br>
> trunk could solve the problem. Using clang at -O2 -g is giving me some<br>
> indication that it won't solve my problem and that we are failing into<br>
> option (2).<br>
> So to summarize, I would be nice if someone can confirm that debug<br>
> informations generated on this specific case are correct for x86 32-bit<br>
and<br>
> that I would have to deal with that.<br>
><br>
> Thanks<br>
> Best Regards<br>
> Seb<br>
><br>
> 2012/3/7 James Molloy <<a href="mailto:james.molloy@arm.com">james.molloy@arm.com</a>><br>
>><br>
>> Hi Seb,<br>
>><br>
>><br>
>><br>
>> I’m going to reiterate – Clang can decide when it wants to optimise away<br>
a<br>
>> variable. You asked for that behaviour when you specified –O2. You can’t<br>
>> expect deterministically the same behaviour on both x86 and x86-64<br>
platforms<br>
>> – the procedure call standards are different and different decisions go<br>
in<br>
>> to deciding how to optimise.<br>
>><br>
>><br>
>><br>
>> You can’t expect debug information for an optimised build to fully track<br>
>> that of the source because by definition the source is being modified to<br>
>> optimise.<br>
>><br>
>><br>
>><br>
>> Cheers,<br>
>><br>
>><br>
>><br>
>> James<br>
>><br>
>><br>
>><br>
>> From: Seb [mailto:<a href="mailto:babslachem@gmail.com">babslachem@gmail.com</a>]<br>
>><br>
>> Sent: 07 March 2012 13:37<br>
>> To: James Molloy<br>
>> Cc: <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>
>> Subject: Re: [LLVMdev] Problem with x86 32-bit debug information ?<br>
>><br>
>><br>
>><br>
>> Hi James,<br>
>><br>
>> clang is able to generate correct debug informations for 64-bit target at<br>
>> -O2. My feeling, given some other experiments I've done,  is that debug<br>
>> information generated for x86 32-bit might be broken for parameters as<br>
long<br>
>> as they are not 'homed' in the code (local copy to an automatic<br>
variable).<br>
>> It seems that when llvm.declare is turned into a llvm.value for parameter<br>
>> there is something incorrect with respect to parameters debug<br>
informations<br>
>> that is generated by clang/llvm. I just would like confirmation of this.<br>
>><br>
>> Thanks for your answer<br>
>> Best Regards<br>
>> Seb<br>
>><br>
>> 2012/3/7 James Molloy <<a href="mailto:james.molloy@arm.com">james.molloy@arm.com</a>><br>
>><br>
>> Hi Seb,<br>
>><br>
>><br>
>><br>
>> Clang cannot generate debug information for something that it has<br>
>> optimised away. You should reduce the optimisation level.<br>
>><br>
>><br>
>><br>
>> In general debug information is only really accurate at –O0.<br>
>><br>
>><br>
>><br>
>> Cheers,<br>
>><br>
>><br>
>><br>
>> James<br>
>><br>
>><br>
>><br>
>> From: <a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a>] On<br>
>> Behalf Of Seb<br>
>> Sent: 07 March 2012 13:17<br>
>> To: <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>
>> Subject: [LLVMdev] Problem with x86 32-bit debug information ?<br>
>><br>
>><br>
>><br>
>> Hi all,<br>
>><br>
>> I'm using trunk version of LLVM/CLANG.<br>
>> When I compile attached files on my 64-bit Ubuntu 10.04 LTS system as<br>
>> follows:<br>
>><br>
>> clang -O2 -g check.c main.c -o check64<br>
>><br>
>> When I do gdb check64 and set a breakpoint to the check routine and<br>
>> executes to the breakpoint, I've got:<br>
>><br>
>> Breakpoint 1, check (result=0x601110, expect=0x601020, n=53) at check.c:7<br>
>> 7    {<br>
>><br>
>> As you can see I can inspect 'n' value.<br>
>><br>
>> Now if I compile for x86 32-bit as follows:<br>
>><br>
>> clang -m32 -O2 -g check.c main.c -o check32<br>
>><br>
>> When I do gdb check32 and set a breakpoint to the check routine and<br>
>> executes to the breakpoint, I've got:<br>
>><br>
>> Breakpoint 1, check (result=<value optimized out>,<br>
>>     expect=<value optimized out>, n=0) at check.c:7<br>
>> 7    {<br>
>><br>
>> As you can see I can NOT inspect 'n' value. Is there a way to inforce<br>
even<br>
>> at -O2 clang to generate debug informations so that I can inspect 'n'<br>
value<br>
>> ?<br>
>> Or is it a BUG from clang for x86 32-bit ?<br>
>> Thanks for your answers.<br>
>> Best Regards<br>
>> Seb<br>
>><br>
>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
I do have to take exception to James Molloy's assessment of the variable "n"<br>
as "optimized away" because the debug info clearly thought it wasn't.  (The<br>
"n=0" shows that the debug info described some kind of location; if "n" was<br>
indeed optimized away, it should have said so.  Either the debug info does<br>
have a bug--giving a location for a nonexistent variable--or something else<br>
is<br>
interfering with our expectations.)<br>
<br>
It is very easy for people to dismiss problems with optimized-code debugging<br>
with a "well, what did you expect??" kind of attitude.  Actually there are<br>
three<br>
broad categories that can apply to any such issue.<br>
<br>
(a) The compiler is trying to keep the debug info in sync with the generated<br>
code, but got it wrong.  This is a correctness bug.<br>
(b) The compiler isn't bothering to keep the debug info in sync with the<br>
generated code, even though it reasonably could do so. This is a<br>
quality-of-implementation issue.<br>
(c) Optimization has made the situation too complicated for the debug info<br>
to<br>
reasonably keep track of things.  This happens.<br>
<br>
There is some slop between the categories, because there are judgement<br>
calls involved in whether something is bad enough to be a bug or is more of<br>
a heuristic that isn't as good as we'd like; equally, there are judgement<br>
calls<br>
in what's a "reasonable" degree of effort to keep track of complicated<br>
cases.<br>
<br>
Blithely tossing every problem into the third category is<br>
inappropriate.  I spent<br>
nontrivial time (on a previous compiler project) tracking down<br>
optimized-code<br>
debugging issues, and probably half of the time I could do something easy to<br>
address it.  Sometimes the compiler was attaching the wrong source location<br>
(bug), sometimes it wasn't bothering to keep track at all even though<br>
it would be<br>
easy (quality of implementation).  In a few cases, generating accurate debug<br>
info required extra analysis, and once or twice we went to that extra<br>
trouble;<br>
the rest of the time, it didn't seem worthwhile (judgement calls).<br>
<br>
Getting down to the specifics of this case, I downloaded the example<br>
programs<br>
and tried them as described.  I got the same behavior as Seb described.<br>
<br>
As for our friend "n=0", after I hit the breakpoint I tried stepping<br>
once.  At that<br>
point, "print n" showed "53" just as we would want.  While it would be ideal<br>
to<br>
see "n=53" at the breakpoint, sometimes debug info and function prologs<br>
don't<br>
line up exactly, and stepping sometimes causes things to become more<br>
sensible.<br>
<br>
So, I think the 32-bit debug info is doing something reasonable, if not<br>
exactly<br>
what you would want.<br>
<br>
Pogo<br>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br>