By the way, the original one-liner patch doesn't seem to fix the double
prompt for me, and it also doesn't fix the case of printing a stack trace
after stopping at a breakpoint through a .lldbinit file. In other words,
this is an interactive session:
d:\src\llvmbuild\ninja\bin>lldb
(lldb) command source -s 1 'd:\src\llvmbuild\ninja\bin\.\.lldbinit'
(lldb) file d:\testexe\simple_step.exe
Current executable set to 'd:\testexe\simple_step.exe' (i686).
(lldb) break set -f simple_step.cpp -l 11
Breakpoint 1: where = simple_step.exe`main + 54 at simple_step.cpp:11,
address = 0x00416096
(lldb) run
Process 11400 launching
(lldb) Process 11400 launched: 'd:\testexe\simple_step.exe' (i686)
(lldb) Process 11400 stopped
* thread #1: tid = 0x376c, 0x00cd6096 simple_step.exe`main(argc=1,
argv=0x01149028) + 54 at simple_step.cpp:11, stop reason = breakpoint 1.1
frame #0: 0x00cd6096 simple_step.exe`main(argc=1, argv=0x01149028) + 54
at simple_step.cpp:11
8
9 int main(int argc, char **argv) {
10 int fib7 = fib(7);
-> 11 printf("The value of fib(7) is %u\n", fib7);
12 return 0;
13 }
(lldb)
If I make a .lldbinit file with the exact same set of commands and start
lldb, I get this output.
d:\src\llvmbuild\ninja\bin>lldb
(lldb) command source -s 1 'd:\src\llvmbuild\ninja\bin\.\.lldbinit'
Process 5288 launching
(lldb) (lldb)
The one-liner patch doesn't change anything for me, so it seems it doesn't
fix everything? I haven't tried the second patch though because of the
ANSI escape codes.
On Mon, Apr 6, 2015 at 3:28 PM Zachary Turner <ztur...@google.com> wrote:
> Hi Greg,
>
> This latest patch appears to have ANSI escape codes in it. Any chance you
> can re-upload?
>
> On Mon, Apr 6, 2015 at 2:41 PM Greg Clayton <gclay...@apple.com> wrote:
>
>> So do you still have problems with the prompt coming out at the wrong
>> time or getting interspersed on FreeBSD with top of tree? It is just made
>> worse by this patch?
>>
>> Try this patch:
>>
>>
>>
>> It changes the Predicate to use a uint32_t instead and it increments the
>> predicate when the process resumes. Clients must first get the current
>> IOHandler ID, then call something that resumes the process (continue or
>> step) and then call Process::SyncIOHandler(iohandler_id, <timeout>).
>>
>> Let me know if this makes anything better or worse?
>>
>> > On Apr 6, 2015, at 2:03 PM, Ed Maste <ema...@freebsd.org> wrote:
>> >
>> > On 6 April 2015 at 16:37, Greg Clayton <gclay...@apple.com> wrote:
>> >> Can everyone try and apply the following patch and run your test suite
>> and also use LLDB for a while?
>> >
>> > Test run looks equivalent on FreeBSD - I had two failures on my desktop:
>> >
>> > FAIL: LLDB (suite) :: TestEvents.py (FreeBSD feynman 10.1-STABLE
>> > FreeBSD 10.1-STABLE #28 r280427+86df2de(stable-10): Thu Mar 26
>> > 16:07:47 EDT 2015
>> > emaste@feynman:/tank/emaste/obj/tank/emaste/src/git-stable-
>> 10/sys/GENERIC
>> > amd64 amd64)
>> > FAIL: LLDB (suite) :: TestSendSignal.py (FreeBSD feynman 10.1-STABLE
>> > FreeBSD 10.1-STABLE #28 r280427+86df2de(stable-10): Thu Mar 26
>> > 16:07:47 EDT 2015
>> > emaste@feynman:/tank/emaste/obj/tank/emaste/src/git-stable-
>> 10/sys/GENERIC
>> > amd64 amd64)
>> >
>> > The first fails intermittently for me under load, while the second has
>> > been failing for a while.
>> >
>> > The change seems to make the lldb-prompt-at-the-wrong-time problem
>> > worse (or at least, no better) during interactive single stepping
>> > though. For example:
>> >
>> > % bin/lldb /bin/ls
>> > (lldb) target create "/bin/ls"
>> > Current executable set to '/bin/ls' (x86_64).
>> > (lldb) b main
>> > Breakpoint 1: where = ls`main + 33 at ls.c:163, address =
>> 0x00000000004023f1
>> > (lldb) run
>> > Process 58244 launching
>> > Process 58244 launched: '/bin/ls' (x86_64)
>> > (lldb) Process 58244 stopped
>> > * thread #1: tid = 103132, 0x00000000004023f1 ls`main(argc=1,
>> > argv=0x00007fffffffe598) + 33 at ls.c:163, stop reason = breakpoint
>> > 1.1
>> > frame #0: 0x00000000004023f1 ls`main(argc=1,
>> > argv=0x00007fffffffe598) + 33 at ls.c:163
>> > 160 #ifdef COLORLS
>> > 161 char termcapbuf[1024]; /* termcap definition buffer */
>> > 162 char tcapbuf[512]; /* capability buffer */
>> > -> 163 char *bp = tcapbuf;
>> > 164 #endif
>> > 165
>> > 166 (void)setlocale(LC_ALL, "");
>> > step
>> > Process 58244 stopped
>> > * thread #1: tid = 103132, 0x00000000004023fa ls`main(argc=1,
>> > argv=0x00007fffffffe598) + 42 at ls.c:166, stop reason = step in
>> > frame #0: 0x00000000004023fa ls`main(argc=1,
>> > argv=0x00007fffffffe598) + 42 at ls.c:166
>> > 163 char *bp = tcapbuf;
>> > 164 #endif
>> > 165
>> > -> 166 (void)setlocale(LC_ALL, "");
>> > 167
>> > 168 /* Terminal defaults to -Cq, non-terminal defaults to
>> -1. */
>> > 169 if (isatty(STDOUT_FILENO)) {
>> > (lldb) step
>> > Process 58244 stopped
>> > * thread #1: tid = 103132, 0x0000000800dab011
>> > libc.so.7`setlocale(category=0, locale=0x0000000000406373) + 33 at
>> > setlocale.c:113, stop reason = step in
>> > frame #0: 0x0000000800dab011 libc.so.7`setlocale(category=0,
>> > locale=0x0000000000406373) + 33 at setlocale.c:113
>> > 110 return (NULL);
>> > 111 }
>> > 112
>> > -> 113 if (locale == NULL)
>> > 114 return (category != LC_ALL ?
>> > 115 current_categories[category] :
>> currentlocale());
>> > 116
>> > (lldb) step
>> > (lldb) Process 58244 stopped
>> > * thread #1: tid = 103132, 0x0000000800dab01a
>> > libc.so.7`setlocale(category=0, locale=0x0000000000406373) + 42 at
>> > setlocale.c:121, stop reason = step in
>> > frame #0: 0x0000000800dab01a libc.so.7`setlocale(category=0,
>> > locale=0x0000000000406373) + 42 at setlocale.c:121
>> > 118 * Default to the current locale for everything.
>> > 119 */
>> > 120 for (i = 1; i < _LC_LAST; ++i)
>> > -> 121 (void)strcpy(new_categories[i],
>> current_categories[i]);
>> > 122
>> > 123 /*
>> > 124 * Now go fill up new_categories from the locale argument
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
