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