https://bugs.llvm.org/show_bug.cgi?id=33250
Bug ID: 33250
Summary: Issue with utf8 string display in the ncurses-GUI mode
on a Beaglebone Black (ARMv6)
Product: lldb
Version: unspecified
Hardware: Other
OS:
Pavel, can you say more about your idea?
In both ObjC and C++ methods, you can refer to an ivar either as "this->ivar"
or just "ivar". But the DWARF for C++ doesn't tell lldb that a particular
language supports referring to ivars transparently this way. It will say that
the "this" parameter
Yes, please fix the first problem.
Thanks!
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
> -Original Message-
> From: Abid, Hafiz [mailto:hafiz_a...@mentor.com]
> Sent: Wednesday, May 31
> On May 31, 2017, at 4:06 AM, Pavel Labath wrote:
>
> Thank you all for the pointers. I am going to look at these to see if
> there is anything that we could reuse, and come back. In the mean
> time, I'll reply to Mathiass's comments:
>
> On 26 May 2017 at 19:11, Matthias Braun wrote:
>>> Bas
Bug reports are here:
https://bugs.llvm.org
It's the same system as for llvm, just specify lldb as the product.
Jim
> On May 28, 2017, at 8:11 AM, Dr. Rolf Jansen via lldb-dev
> wrote:
>
> I managed to build LLDB on a Beaglebone Black running a snapshot (May 20th)
> of FreeBSD 12.0-CURRENT
Pavel Labath schrieb:
> I think the cleanest solution would be to actually modify the compiler
> to emit "correct" dwarf (as in, dwarf representing the code as it
> actually looks like to user, and not some internal intermediate
> representation). The dwarf expression in DW_AT_location can easily
>
I see 2 problems here. CMICmdCmdVarUpdate::ExamineSBValueForChange seems to
ignore the changes in in children
for pointer and references. It is easy enough to fix. The other issue is that
we dont not print the changed child value.
For example, with the first issue fixed, I get
-var-update 1 var
Thank you all for the pointers. I am going to look at these to see if
there is anything that we could reuse, and come back. In the mean
time, I'll reply to Mathiass's comments:
On 26 May 2017 at 19:11, Matthias Braun wrote:
>> Based on a not-too-detailed examination of the lit codebase, it does
>
I think the cleanest solution would be to actually modify the compiler
to emit "correct" dwarf (as in, dwarf representing the code as it
actually looks like to user, and not some internal intermediate
representation). The dwarf expression in DW_AT_location can easily
handle the lookup of some field
