Just a heads-up for other LLDB users...

The last few days I've been driven nuts by Xcode failing to stop at some breakpoints (it just lists them as pending). I've now tracked this down to the use of UNIFIED_SOURCES. The issue is explained here:

  http://lldb.llvm.org/troubleshooting.html

Unfortunately, setting target.inline-breakpoint-strategy to "always" doesn't actually seem to work with the LLDB that comes with Xcode 5.0.1, and my experience of LLDB builds that I've created myself has been that they're pretty unstable.

I'm not sure how best to handle this just yet, but given this...

On 19/11/2013 03:04, L. David Baron wrote:
On Monday 2013-11-18 18:44 -0500, Ehsan Akhgari wrote:
On 2013-11-17 7:50 PM, L. David Baron wrote:
Could we do a static analysis to look for things whose semantics are
changed by this unification, such as statics with the same name
between files that are/might be unified?  (And could we make the
tree turn red if it failed?)

That analysis is quite hard to perform if we try to catch all kinds
of such leakage.  I think a periodic non-unified build is a much
better way of discovering such problems.

I'm inclined to think it'll need to be more than periodic, actually.

I expect that otherwise we'd get pretty frequent bustage with people
forgetting to add #includes, and that bustage would then show up
when we add or remove files, which would make it a huge pain to add
or remove files.

But I'm actually also worried (perhaps *more* worried) about cases
where there are semantic differences but things will still compile,
such as two static variables of the same name and type, in different
files (e.g., "static bool gInitialized").  We could end up with
breakage both because of code that expects such variables to be
distinct, or from new code that expects such variables to be merged.

I may end up being the guinea pig that is perpetually having his builds broken because he has to have a patch applied to revert all UNIFIED_SOURCES lines back to SOURCES lines in order to debug anything...

Jonathan

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to