labath added inline comments.
================
Comment at: lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp:637
if (location_sp->GetName() == g_size_name)
- location_sp = short_sp->GetChildAtIndex(3, true);
+ location_sp = short_sp->GetChildAtIndex(2, true);
if (using_bitmasks)
----------------
ldionne wrote:
> mib wrote:
> > mib wrote:
> > > aprantl wrote:
> > > > Let me know if I',m misunderstanding what the code is doing, but this
> > > > looks like it is replacing the previous implementation? Ideally we
> > > > would detect the layout and then parse it correctly depending on which
> > > > version we're dealing with. Otherwise we risk breaking the matrix bot
> > > > that checks that LLDB can debug C++ produced by older versions of LLVM
> > > > (and by extension libcxx).
> > > I've look at D12828 and D123580, and I don't see any way of versioning
> > > these changes ... may be @ldionne have an idea on how we could do this
> > > properly ?
> > >
> > > Also, in D124113, @labath mentions that this data formatter uses mostly
> > > indices to parse and access the various fields of the type data structure
> > > (because it uses some anonymous structs). This makes it very fragile on
> > > our end because our data formatter break every time they make a change in
> > > the layout ...
> > >
> > > @aprantl, I'll update the line your pointed at to the the field
> > > identifier instead of using changing the index while waiting for a better
> > > way to version this.
> > @aprantl, I'll update the line you pointed at to *use* the field identifier
> > instead of using changing the index, while waiting for a better way to
> > version this.
> I don't see a way to version this. You don't have access to the value of
> macros that were defined when the executable was compiled, right? If you did,
> you could check `_LIBCPP_VERSION` (1400 = old implementation, 1500 = current
> implementation). I'm very naive when it comes to debuggers but I assume
> that's not possible.
There is no fundamental problem in versioning this. Using the macro is not the
best idea (some compilers, in some build modes, may emit it, but I wouldn't
want to rely on it), but pretty much anything else is fair game. The presence
or absence of an anonymous struct is recorded in the debug info, so using that
to decide on the layout is definitely doable (and my follow-up patch does that).
However, I would say that the real, and totally self-inflicted, problem here
(besides the fact that we want to format all possible string layouts with a
single piece of code) is that the API we're using here does not treat anonymous
classes transparently. Ideally, this kind of change shouldn't even be noticed.
If I use the user-facing "frame var" command to look inside the string object,
then the expression `__r_.__value_.__s.__is_long_` works regardless of how many
anonymous classes it has to go through. The fact that we have to worry about
_that_ here, when there's already so many other things (v1 vs v2, historical
layouts, corrupt strings, corrupt debug info, ...) to worry about is just bad.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D128694/new/
https://reviews.llvm.org/D128694
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
