Re: [lldb-dev] A bit of extra-polish for my lldb plugin
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 in a struct. Of course, this is
assuming you are actually able to modify the compiler.
(disclaimer: I know next to nothing, when it comes to objc)
On 26 May 2017 at 23:25, Jim Ingham via lldb-dev
wrote:
> Because we try as much as possible to let the compiler figure this sort of
> thing out for us, we implement the transparent lookups for this & self by
> compiling our expression in a context that poses as a method of the class
> whose method we are stopped in. For instance, for ObjC, we construct a
> category on the class, and put the expression text in a method in that
> category, and then compile all that and call the method.
>
> That's done in ExpressionSourceCode::GetText.
>
> The one hitch to this is that this works because the compiler that is linked
> into lldb knows about the ObjC model we are emulating. An unmodified clang
> won't do transparent lookup into some random argument that happens to be
> called _param. So you would have to build lldb with a version of clang that
> understands your lookup rules for this to work.
>
> If that's not possible then you can try to do this by monkeying with the
> lookup rules implemented by lldb's ClangASTSource to return "_param.a" when
> it is just looking up "a". That's how we inject variables and types that are
> present in the local context into the expression as it is getting parsed.
> But at that point you are getting your hands into some fairly deep magic, and
> clang's Aslan is not as forgiving as Narnia's...
>
> Jim
>
>
>> On May 26, 2017, at 2:27 PM, Nat! via lldb-dev
>> wrote:
>>
>> Let me show you a snippet of a lldb debug session in progress in my ObjC
>> variant:
>>
>> ```
>> -10,10,v,18.48
>> Process 45774 stopped
>> * thread #1, queue = 'com.apple.main-thread', stop reason = step in
>>frame #0: 0x00010e2a multiple.debug`+[Foo
>> long:int:char:float:](self=Foo, _cmd=,
>> _param=0x7fff5fbff948) at multiple.m:15
>> 12 char:(char) c
>> 13 float:(float) d
>> 14 {
>> 15 printf( "%ld,%d,%c,%.2f\n", a, b, c, d);
>> -> 16 }
>> 17
>> 18 @end
>> (lldb) p *_param
>> (p.long:int:char:float:) $2 = (a = -10, b = 10, c = 'v', d =
>> 18.475)
>> ```
>>
>> You can see that the parameter values `a,b,c,d` are actually fields of
>> a struct parameter `_param`. `_param` uniformly appears as the third
>> parameter after `self` and `_cmd`. `p _param->a` works of course, but it
>> would be nice to be able to say 'p a', since in the source code one sees
>> only `a`. `_param` is more or less an implementation detail.
>>
>> A clue how to achieve this, would be very much appreciated.
>>
>> Ciao
>> Nat!
>>
>>
>> [*] except, if it's a picture of thousand words :)
>>
>> https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_meta_call_convention.html
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Running lit (googletest) tests remotely
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 >> not seem that it would be too difficult to add this capability: During >> test discovery phase, we could copy the required files to the remote >> host. Then, when we run the test, we could just prefix the run command >> similarly to how it is done for running the tests under valgrind. It >> would be up to the user to provide a suitable command for copying and >> running files on the remote host (using rsync, ssh, telnet or any >> other transport he chooses). > > This seems to be the crux to me: What does "required files" mean? > - All the executables mentioned in the RUN line? What llvm was compiled as a > library, will we copy those too? For executables, I was considering just listing them explicitly (in lit.local.cfg, I guess), although parsing the RUN line should be possible as well. Even with RUN parsing, I expect we would some way to explicitly add files to the copy list (e.g. for lldb tests we also need to copy the program we are going to debug). As for libraries, I see a couple of solutions: - declare these configurations unsupported for remote executions - copy over ALL shared libraries - have automatic tracking of runtime dependencies - all of this information should pass through llvm_add_library macro, so it should be mostly a matter of exporting this information out of cmake. These can be combined in the sense that we can start in the "unsupported" state, and then add some support for it once there is a need for it (we don't need it right now). > - Can tests include other files? Do they need special annotations for that? My initial idea was to just copy over all files in the Inputs folder. Do you know of any other dependencies that I should consider? > > As another example: The llvm-testsuite can perform remote runs > (test-suite/litsupport/remote.py if you want to see the implementation) that > code makes the assumption that the remote devices has an NFS mount so the > relevant parts of the filesystem look alike on the host and remote device. > I'm not sure that is the best solution as NFS introduces its own sort of > flakiness and potential skew in I/O heavy benchmarks but it avoids the > question of what to copy to the device. Requiring an NFS mount is a non-starter for us (no way to get an android device to create one), although if we would be able to hook in a custom script which does a copy to simulate the "mount", we might be able to work with it. Presently I am mostly thinking about correctness tests, and I am not worried about benchmark skews regards, pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] issue with lldb-mi -var-update with pointers
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 var0
^done,changelist=[{name="var0",value="0x7fffed30",in_scope="true",type_changed="false",has_more="0"}]
This problem exist for aggregate types too.
I think I can put the fix for the first problem if it will help you. Please let
me know.
Thanks,
Abid
From: lldb-dev on behalf of Ted Woodward via
lldb-dev
Sent: Tuesday, May 30, 2017 9:50 PM
To: 'LLDB'
Subject: [lldb-dev] issue with lldb-mi -var-update with pointers
I have a simple testcase that modifies the value pointed to by an int *.
I've created a variable with -var-create, and then after the value has been
updated, check it with -var-update. -var-update returns no changes, but the
value has changed.
test.c:
#include
int main(void)
{
int vec[] = {1, 2, 3, 4};
int foo = 0;
int *bar = &foo;
int i = 0;
for (i = 0; i < 4; i++)
*bar += vec[i];
return foo;
}
Commands:
-break-insert -t -f test.c:10
-break-insert -t -f test.c:13
-exec-run
-var-create --thread 1 --frame 0 - * bar
-var-list-children var0
-var-evaluate-expression var0.*bar
-exec-continue
1 var0
-var-evaluate-expression var0.*bar
Output:
(gdb)
-var-create --thread 1 --frame 0 - * bar
^done,name="var0",numchild="1",value="0x7fffed30",type="int
*",thread-id="1",has_more="0"
(gdb)
-var-list-children var0
^done,numchild="1",children=[child={name="var0.*bar",exp="*bar",numchild="0"
,type="int",thread-id="1",has_more="0"}],has_more="0"
(gdb)
-var-evaluate-expression var0.*bar
^done,value="0"
***Value is 0
(gdb)
-exec-continue
^running
(gdb)
=thread-exited,id="1",group-id="i1"
(gdb)
*running,thread-id="all"
(gdb)
=thread-created,id="1",group-id="i1"
(gdb)
*stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={level="0",addr
="0x00400530",func="main",args=[],file="test.c",fullname="/local/scr
atch/ted/tip/newfull/test.c",line="13"},thread-id="1",stopped-threads="all"
(gdb)
-var-update 1 var0
^done,changelist=[]
***No changes
(gdb)
-var-evaluate-expression var0.*bar
^done,value="10"
***Value is 10, even though we reported no changes.
The child shows an update:
(gdb)
-var-update 1 var0.*bar
^done,changelist=[{name="var0.*bar",value="10",in_scope="true",type_changed=
"false",has_more="0"}]
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] A bit of extra-polish for my lldb plugin
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 > handle the lookup of some field in a struct. Of course, this is > assuming you are actually able to modify the compiler. > > (disclaimer: I know next to nothing, when it comes to objc) > That would probably be ideal. I have to see if I can do this. But my metaABI is somewhat "hacked" into clang. So I am not saying it wouldn't work, but I suspect it won't, as I am relying on existing clang code. Ciao Nat! ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] issue with utf8 string display in the ncurses-GUI mode on a Beaglebone Black (ARMv6)
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 -- ARMv6. This is the first LLDB of all that I tried > out, which let me single step into the code, so I am already quite happy with > it. In the moment, I see only one minor issue left to be resolved, namely > UTF8 strings are not displayed correctly in the ncurses-GUI mode, while in > cli mode I see no issue. > > This happens in the ncurses-GUI mode of LLDB 3.9.1, LLDB 4.0.1, up to LLDB > 5.0.0 (svn). > > This is an ARM issue, since it does not occur on x86 machines. Perhaps this > might be related to the signed/unsigned char mismatch between ARM and x86. > Other ncurses software on the Beaglebone does work well under FreeBSD. > > I did not find a bug-reporting facility for LLDB. In case, I need to submit a > bug report on this, please may I ask for a link. > > Best regards > > Rolf > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Running lit (googletest) tests remotely
> 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: >>> Based on a not-too-detailed examination of the lit codebase, it does >>> not seem that it would be too difficult to add this capability: During >>> test discovery phase, we could copy the required files to the remote >>> host. Then, when we run the test, we could just prefix the run command >>> similarly to how it is done for running the tests under valgrind. It >>> would be up to the user to provide a suitable command for copying and >>> running files on the remote host (using rsync, ssh, telnet or any >>> other transport he chooses). >> >> This seems to be the crux to me: What does "required files" mean? >> - All the executables mentioned in the RUN line? What llvm was compiled as a >> library, will we copy those too? > For executables, I was considering just listing them explicitly (in > lit.local.cfg, I guess), although parsing the RUN line should be > possible as well. Even with RUN parsing, I expect we would some way to > explicitly add files to the copy list (e.g. for lldb tests we also > need to copy the program we are going to debug). > > As for libraries, I see a couple of solutions: > - declare these configurations unsupported for remote executions > - copy over ALL shared libraries > - have automatic tracking of runtime dependencies - all of this > information should pass through llvm_add_library macro, so it should > be mostly a matter of exporting this information out of cmake. > These can be combined in the sense that we can start in the > "unsupported" state, and then add some support for it once there is a > need for it (we don't need it right now). Sounds good. An actively managed list of files to copy in the lit configuration is a nice simple solution provided we have some regularily running public bot so we can catch missing things. But I assume setting up a bot was your plan anyway. > >> - Can tests include other files? Do they need special annotations for that? > My initial idea was to just copy over all files in the Inputs folder. > Do you know of any other dependencies that I should consider? I didn't notice that we had already developed a convention with the "Inputs" folders, so I guess all that is left to do is making sure all tests actually follow that convention. > >> >> As another example: The llvm-testsuite can perform remote runs >> (test-suite/litsupport/remote.py if you want to see the implementation) that >> code makes the assumption that the remote devices has an NFS mount so the >> relevant parts of the filesystem look alike on the host and remote device. >> I'm not sure that is the best solution as NFS introduces its own sort of >> flakiness and potential skew in I/O heavy benchmarks but it avoids the >> question of what to copy to the device. > > Requiring an NFS mount is a non-starter for us (no way to get an > android device to create one), although if we would be able to hook in > a custom script which does a copy to simulate the "mount", we might be > able to work with it. Presently I am mostly thinking about correctness > tests, and I am not worried about benchmark skews Sure, I don't think I would end up with an NFS mount strategy if I would start fresh today. Also the test-suite benchmarks (esp. the SPEC) ones tend to have more complicated harder to track inputs. - Matthias ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] issue with lldb-mi -var-update with pointers
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, 2017 7:09 AM
> To: Ted Woodward
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] issue with lldb-mi -var-update with pointers
>
> 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 var0
> ^done,changelist=[{name="var0",value="0x7fffed30",in_scope="tru
> e",type_changed="false",has_more="0"}]
>
> This problem exist for aggregate types too.
>
> I think I can put the fix for the first problem if it will help you.
Please let me
> know.
>
> Thanks,
> Abid
>
> From: lldb-dev on behalf of Ted
> Woodward via lldb-dev
> Sent: Tuesday, May 30, 2017 9:50 PM
> To: 'LLDB'
> Subject: [lldb-dev] issue with lldb-mi -var-update with pointers
>
> I have a simple testcase that modifies the value pointed to by an int *.
> I've created a variable with -var-create, and then after the value has
been
> updated, check it with -var-update. -var-update returns no changes, but
the
> value has changed.
>
> test.c:
> #include
>
> int main(void)
> {
> int vec[] = {1, 2, 3, 4};
> int foo = 0;
> int *bar = &foo;
> int i = 0;
>
> for (i = 0; i < 4; i++)
> *bar += vec[i];
>
> return foo;
> }
>
> Commands:
> -break-insert -t -f test.c:10
> -break-insert -t -f test.c:13
> -exec-run
> -var-create --thread 1 --frame 0 - * bar -var-list-children var0
-var-evaluate-
> expression var0.*bar -exec-continue
> 1 var0
> -var-evaluate-expression var0.*bar
>
>
> Output:
> (gdb)
> -var-create --thread 1 --frame 0 - * bar
> ^done,name="var0",numchild="1",value="0x7fffed30",type="int
> *",thread-id="1",has_more="0"
> (gdb)
> -var-list-children var0
> ^done,numchild="1",children=[child={name="var0.*bar",exp="*bar",numch
> ild="0"
> ,type="int",thread-id="1",has_more="0"}],has_more="0"
> (gdb)
> -var-evaluate-expression var0.*bar
> ^done,value="0"
>
> ***Value is 0
>
> (gdb)
> -exec-continue
> ^running
> (gdb)
> =thread-exited,id="1",group-id="i1"
> (gdb)
> *running,thread-id="all"
> (gdb)
> =thread-created,id="1",group-id="i1"
> (gdb)
> *stopped,reason="breakpoint-
> hit",disp="del",bkptno="2",frame={level="0",addr
> ="0x00400530",func="main",args=[],file="test.c",fullname="/local/s
> cr
>
atch/ted/tip/newfull/test.c",line="13"},thread-id="1",stopped-threads="all"
> (gdb)
> -var-update 1 var0
> ^done,changelist=[]
>
> ***No changes
>
> (gdb)
> -var-evaluate-expression var0.*bar
> ^done,value="10"
>
> ***Value is 10, even though we reported no changes.
>
> The child shows an update:
> (gdb)
> -var-update 1 var0.*bar
> ^done,changelist=[{name="var0.*bar",value="10",in_scope="true",type_ch
> anged=
> "false",has_more="0"}]
>
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] A bit of extra-polish for my lldb plugin
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 is artificial, and that it is the "object pointer". But
it doesn't so far as I can tell record the fact that elements of that parameter
can be transparently accessed.
I think it would be confusing for the debug information to record the
transparently accessed ivars as pseudo-locals, the duplication would confuse
folks, and that isn't how they are understood by the person writing the code.
It might be good to propose a "DW_AT_transparent" attribute, and mark the ivars
or maybe the parameter that way. I guessing that wasn't done because it was
assumed that the debugger would know this sort of rule from the language in
question.
As I understand it, problem here is that Nat's runtime has extra rules for
transparent access that lldb doesn't know about.
Jim
> On May 31, 2017, at 3:20 AM, Pavel Labath wrote:
>
> 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 in a struct. Of course, this is
> assuming you are actually able to modify the compiler.
>
> (disclaimer: I know next to nothing, when it comes to objc)
>
> On 26 May 2017 at 23:25, Jim Ingham via lldb-dev
> wrote:
>> Because we try as much as possible to let the compiler figure this sort of
>> thing out for us, we implement the transparent lookups for this & self by
>> compiling our expression in a context that poses as a method of the class
>> whose method we are stopped in. For instance, for ObjC, we construct a
>> category on the class, and put the expression text in a method in that
>> category, and then compile all that and call the method.
>>
>> That's done in ExpressionSourceCode::GetText.
>>
>> The one hitch to this is that this works because the compiler that is linked
>> into lldb knows about the ObjC model we are emulating. An unmodified clang
>> won't do transparent lookup into some random argument that happens to be
>> called _param. So you would have to build lldb with a version of clang that
>> understands your lookup rules for this to work.
>>
>> If that's not possible then you can try to do this by monkeying with the
>> lookup rules implemented by lldb's ClangASTSource to return "_param.a" when
>> it is just looking up "a". That's how we inject variables and types that
>> are present in the local context into the expression as it is getting
>> parsed. But at that point you are getting your hands into some fairly deep
>> magic, and clang's Aslan is not as forgiving as Narnia's...
>>
>> Jim
>>
>>
>>> On May 26, 2017, at 2:27 PM, Nat! via lldb-dev
>>> wrote:
>>>
>>> Let me show you a snippet of a lldb debug session in progress in my ObjC
>>> variant:
>>>
>>> ```
>>> -10,10,v,18.48
>>> Process 45774 stopped
>>> * thread #1, queue = 'com.apple.main-thread', stop reason = step in
>>> frame #0: 0x00010e2a multiple.debug`+[Foo
>>> long:int:char:float:](self=Foo, _cmd=,
>>> _param=0x7fff5fbff948) at multiple.m:15
>>> 12 char:(char) c
>>> 13 float:(float) d
>>> 14 {
>>> 15 printf( "%ld,%d,%c,%.2f\n", a, b, c, d);
>>> -> 16 }
>>> 17
>>> 18 @end
>>> (lldb) p *_param
>>> (p.long:int:char:float:) $2 = (a = -10, b = 10, c = 'v', d =
>>> 18.475)
>>> ```
>>>
>>> You can see that the parameter values `a,b,c,d` are actually fields of
>>> a struct parameter `_param`. `_param` uniformly appears as the third
>>> parameter after `self` and `_cmd`. `p _param->a` works of course, but it
>>> would be nice to be able to say 'p a', since in the source code one sees
>>> only `a`. `_param` is more or less an implementation detail.
>>>
>>> A clue how to achieve this, would be very much appreciated.
>>>
>>> Ciao
>>> Nat!
>>>
>>>
>>> [*] except, if it's a picture of thousand words :)
>>>
>>> https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_meta_call_convention.html
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 33250] New: Issue with utf8 string display in the ncurses-GUI mode on a Beaglebone Black (ARMv6)
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: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: r...@obsigna.com
CC: llvm-b...@lists.llvm.org
I built (lldb + clang/lld) from the svn trunk of LLVM 5.0.0 on my Beaglebone
Black running the latest snapshot (May 26th) of FreeBSD 12.0-CURRENT.
# lldb --version
lldb version 5.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision
304078)
clang revision 304078
llvm revision 304078
However, the present issue can be found in lldb at least since 3.8.
First of all, my system's locale is:
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=
$echo $TERM
xterm-256color
Now, please consider the following tiny ncurses test program 'cursutf8.c',
which prints out the traditional German pangram for testing the special
characters 'ä', 'ö', 'ü', 'ß', each of which consists of two bytes when encoded
in UTF8:
#include
#include
#include
#include
int main(int argc, char *argv[])
{
setlocale(LC_CTYPE, "");
WINDOW *window = initscr();
if (window)
{
mvaddstr(3, 3, "Zwölf Boxkämpfer jagen Viktor quer über den großen Sylter
Deich.");
refresh();
sleep(3);
delwin(window);
endwin();
refresh();
return 0;
}
else
return 1;
}
I compile this using:
$clang -g -O0 cursutf8.c -lncursesw -o cursutf8
When I run it, it correctly prints out:
Zwölf Boxkämpfer jagen Viktor quer über den großen Sylter Deich.
Then I start this with lldb:
$lldb -- cursutf8
(lldb) breakpoint set -f cursutf8.c -l 13
(lldb) run
Process 13886 stopped
* thread #1, name = 'cursutf8', stop reason = breakpoint 1.1
frame #0: 0x8a08 cursutf8`main(argc=1, argv=0xbfbfec74) at cursutf8.c:13
10 WINDOW *window = initscr();
11 if (window)
12 {
-> 13 mvaddstr(3, 3, "Zwölf Boxkämpfer jagen Viktor quer über den
großen Sylter Deich.");
14 refresh();
15 sleep(3);
16
So far this is OK as well.
The issue shows up, when I enter into the GUI mode:
(lldb) gui
│ 10 │WINDOW *window = initscr();
│ 11 │if (window)
│ 12 │{
│ 13 │◆ mvaddstr(3, 3, "ZwM-CM-6lf BoxkM-CM-$mpfer jagen Viktor quer
M-CM-___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
