[PATCH] D56913: decoupling Freestanding atomic<T> from libatomic.a

[Jim Ingham via llvm-commits]

Yes, I'm fine with that too.  So long as the bots are green mostly, we figure this sort of thing out quickly.  Also, since one of the rules of the data formatters we ship with lldb is that they don't run code, we pretty much always depend on the layout of the class.  So if you are changing the internal layout of a standard library type, you probably will break the data formatter for that type - if it exists.  So just ping us when you are doing that and we can work together to figure out how to fix the formatters.

I certainly wouldn't want to discourage contributions to C++ formatters, however.   After all, though we will get to writing useful formatters for all the C++ standard library types that need them at some point we're not there yet (and more types keep coming along).  We react either to (a) wanting to see the type because we are using it in our code or (b) getting a bug with enough dups to bubble it up in our queue. So more obscure types may wait a long time to get support in lldb.  If somebody is working on a standard library type that doesn't show nicely in the debugger, it would be nice to leave time in your development to improve that.  Ping one of us, we'll be happy to help.

But it does seem more workable for now to leave the formatters in lldb and test them through lldb.

Jim


> On Mar 4, 2019, at 2:19 PM, Davide Italiano <dccitaliano at gmail.com> wrote:
> 
> On Mon, Mar 4, 2019 at 1:07 PM Louis Dionne <ldionne at apple.com> wrote:
>> 
>> 
>> 
>>> On Mar 4, 2019, at 15:41, Jim Ingham <jingham at apple.com> wrote:
>>> 
>>> lldb data formatters can be written using the lldb SB API's from either Python or from C++, and lldb can load both Python modules defining data formatters or shared libraries ditto. One of the reasons we structured the data formatters the way we did was just so that library authors could support their own formatters.  Somehow, however, most library authors have been content for us to do the work for them ;-)  But if the libc++ maintainers wanted to take over maintaining the lldb data formatters for C++, there's nothing technical stopping them from doing so.  The SB API's are lldb's stable API's so data formatters written this way will work across a wide range of lldb versions.  We'd have to figure out packaging issues and the like, but if there's interest on your end this should be doable (*).
>>> 
>>> BTW, another suggestion that has been floated is to come up with a debugger independent representation of the "important bits" of a class from which debuggers could synthesize a data formatter.  I'm not sure how easy it would be to come up with a rich enough description but up-sides would be that multiple debuggers could then support the rich view of the class, and the specification could live in the headers themselves, so distribution wouldn't be a problem.  This idea does seem like a bigger project...
>>> 
>>> (*) Note, for reasons of expediency the current C++ data formatters are written using the lldb_private API's, which are not for external use.  That was in hindsight an unfortunate choice, it does mean the formatters would have to be rewritten from their current form to live separately from lldb.
>> 
>> I think libc++ maintainers do not have sufficient bandwidth to migrate the data formatters (especially given the relatively low value added compared to other libc++ tasks). However, if someone else migrated the data formatters to libc++ and they were relatively easy to maintain, what I'm saying is that I'd be willing to make sure that we don't break those formatters when we make new commits. That is contingent on the formatters being tested as part of libc++, like I said before.
>> 
>> Otherwise, in good faith, I'll try to remember running the data formatters when we change the ABI (even if that's not sufficient). But running the lldb test suite is too disruptive to the workflow to systematically run it pre-commit on each libc++ change. The status-quo is workable too -- we sometimes (but rarely) break the formatters, get notified by CI, and someone that knows the formatters well fixes the problem.
>> 
>> Louis
>> 
> 
> Other people are working on this area of the codebase, and I touch it
> relatively infrequently to have a strong opinion, but I'm under the
> impression the status quo isn't really unreasonable.
> Sometimes things break, and we fix them. The worst thing that can
> happen is that the libcxx change is reverted for a short amount of
> time until the issue is sorted out. No biggie.
> 
> --
> Davide