Again, I'd like to separate the concerns of "supporting code built with 
-fno-standalone-debug" in real life and supporting it in the testsuite.  If 
what's mostly going on in the testsuite is that this option makes the 
compiler's "you're not using it so you get no debug info for it" optimization 
too aggressive for the style of code you write in test suites (which is quite 
artificial, not much significant code is 30 or 40 lines long in toto, mostly 
defining things so we can poke at them) then it doesn't seem like getting 
ourselves into a fight with the compiler in this venue is really worth the 
effort.  My suspicion is that this is what is going on, just because we don't 
have a lot of complex classes in the testsuite, but I don't have time to chase 
this down right now.

This is not to take a stance one way or the other about support for 
-fno-standalone-debug.  I'm just saying that in the past it has always been 
tricky to write test cases that the compiler's desire to reduce debug info 
doesn't fight against.  In "normal" code this generally sorts itself out 
because there isn't much of interest which gets introduced to your code that 
somebody doesn't use somewhere...  But having to write more complex than 
necessary test cases just so we can win this fight against the compiler seems a 
waste of time.

And of course as we work to support -fno-standalone-debug we could add some 
test cases that exercise the kinds of elisions that cause trouble IRL.  Just 
maybe not impose that burden on the whole testsuite.

Jim
 

> On Jul 13, 2014, at 2:08 PM, Ed Maste <[email protected]> wrote:
> 
> On 11 July 2014 00:18, Reid Kleckner <[email protected]> wrote:
>> Anyway, we should try to figure something out.  I understand if you're not
>> interested in pursuing this work, I just hope that patches to make LLDB
>> smarter about this are welcome, and that we can help out as necessary on the
>> Clang side.
> 
> I'd really like to see this get sorted out.  Right now on FreeBSD we
> also have -fstandalone-debug enabled by default due to this and other
> reasons; I'd really like to be able to turn it back off.  I haven't
> seen anything to suggest there would be an objection to improving this
> in LLDB.
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to