[lldb-dev] test system, when using clang, flags

[Todd Fiala]

I was looking to have this flag set in the test suite to just avoid cases
where MacOSX test results differ from Linux test results because of the
different clang behaviors on the two systems w/r/t debug info.  Right now
we have a large number of tests marked XFAIL on Linux, and I'm looking for
easy ways to reduce differences between the MacOSX and Linux test suite.
 Debug info presence/absence/differences, in a debugger test suite, seem a
pretty significant difference.

However, Jim has convinced me that for our relatively small main.cpp files,
this is probably not a significant cause of difference enough to blanket
change it without having some proof that it is the issue.  Besides, if it
ends up being the flag that is the issue, having one platform that the flag
one way and another that runs it the other is perhaps a better test of lldb
anyway, assuming we get them all to pass in the end :-)

-Todd


On Mon, Jul 14, 2014 at 12:03 PM, <jingham at apple.com> wrote:

> I haven't kept track of clang's debug reduction flags.  There used to be
> an -funused-types or -funused-declarations or something like that that
> covered not emitting type information declarations (originally in gcc it
> was just types, then it was made into all declarations.)  That is pretty
> much always on, and our test cases work with that on (for instance we'd
> never write a test like the one you cite, since it would pretty much never
> work.)  I don't know what extra -fno-standalone-debug does that is tripping
> up the testsuite.  But again, I don't have any time to look into it either.
>
> Jim
>
>
> > On Jul 14, 2014, at 11:50 AM, Reid Kleckner <rnk at google.com> wrote:
> >
> > I'm actually kind of curious what kinds of test code this is breaking.
>  I'm imagining this program:
> >
> > struct A {
> >   virtual void foo();
> >   int x;
> > };
> > uintptr_t buf[2] = { 0xdeadbeef, 0x1234 };
> > int main() {}
> >
> > (lldb) print *(A*)buf
> >
> > In this case, there will be no debug info for A, and the program still
> compiles and links, because nobody ever created an A.
> >
> > It isn't really here or there, though, since it sounds like nobody has
> time to work on this at the moment.
> >
> >
> > On Mon, Jul 14, 2014 at 11:20 AM, <jingham at apple.com> wrote:
> > 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 <emaste at freebsd.org> wrote:
> > >
> > > On 11 July 2014 00:18, Reid Kleckner <rnk at google.com> 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
> > > lldb-dev at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>



-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140714/a8932fb6/attachment.html>