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

[Jim Ingham via libcxx-commits]

> On Mar 4, 2019, at 4:09 PM, Shafik Yaghmour via Phabricator <reviews at reviews.llvm.org> wrote:
> 
> shafik added a comment.
> 
> In D56913#1417291 <https://reviews.llvm.org/D56913#1417291>, @ldionne wrote:
> 
>> In D56913#1417198 <https://reviews.llvm.org/D56913#1417198>, @davide wrote:
>> 
>>> In D56913#1417184 <https://reviews.llvm.org/D56913#1417184>, @__simt__ wrote:
>>> 
>>>> In D56913#1417172 <https://reviews.llvm.org/D56913#1417172>, @davide wrote:
>>>> 
>>>>> This commit broke the atomic lldb data formatter.
>>>>> 
>>>>> http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/21037/
>>>>> 
>>>>> @shafik @jingham
>>>> 
>>>> 
>>>> It looks like LLDB is naming internal names here. Unfortunately, it now needs to learn the new names. On the plus side, there is now a single stable internal name for all compilation paths for this header, whereas it used to differ. So the final result ought to be seen as an improvement.
>>> 
>>> 
>>> Nobody disagrees but the formatter has to be fixed, hence the two people cc:ed.
>> 
>> 
>> Sorry -- I should have run the tests for the LLDB formatters. This is not the first time it happens.
>> 
>> However, seeing how error-prone it is to change something in libc++ without running the LLDB tests, would it make sense to test the data formatters as part of libc++ itself? One way to see the data formatters is as something that libc++ provides to work nicely with LLDB instead of as something LLDB tries to provide for libc++. When seen that way, it makes more sense that the data formatters use private parts of libc++, and the tests should be part of libc++'s test suite. I don't know how big of a change this is, but I'd encourage LLDB folks to consider this as this would reduce a cause of semi-frequent mistakes.
> 
> 
> Some of us had a brief discussion about this and it would probably require us to move them to python as opposed to C++ and that would not be a trivial amount of work.

I don't see why you would be required to move to Python.  You can write data formatters with the C++ SB API, and lldb has a command (plugin load) that will load a C++ dylib and run a specified initialization routine to load all your data formatters, etc.  So you would be able to write the formatters in C++.  The pertinent issue is that the current data formatters are written against the lldb_private API's, and those symbols are not exported from lldb, nor should they be. So to have truly independent data formatters for libc++, we would have to rewrite the formatters to use the SB API's.  If you are a C++ programmer, rewriting them to use the C++ SB API's is probably easier than using the Python version, and you could likely reuse some of the existing code.  Still, either project (lldb_private -> C++ SB or lldb_private ->Python SB) would be a fair amount of work.

I think we agreed that its best to leave things as is and just make sure we react quickly to breakages.  But I didn't want anyone getting a false impression of what was possible.

Jim


> 
> I have a fix that I am testing now, I would be happy to explain it to anyone interested in understanding how to work with the formatters once I commit it.
> 
> 
> Repository:
>  rL LLVM
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D56913/new/
> 
> https://reviews.llvm.org/D56913
> 
> 
>