Re: [lldb-dev] LLDB/NetBSD extended set of tasks

[Jim Ingham via lldb-dev]

The main consumer of thread stop reasons is the execution control (ThreadPlans 
- which handle stepping & function calling - and StopInfo::PerformAction which 
handles breakpoint/watchpoint hits).  The only bad effect of populating all the 
threads with the whole process signals is if any of the plans did anything 
special with that signal.  Some of the thread plans do care about a few 
signals, but those are mostly SIGSEGV and the like (the function calling plans 
care about this.)  I can't see what it would mean to send a whole process 
SIGSEGV, however, that seems like it is always going to be a thread specific 
thing.  Ditto for however you see a breakpoint hit (SIGTRAP?)  Those really 
have to be thread specific...

I can't think of anything else this would really affect, so going forward with 
your "process => all threads" fiction is probably fine for a first pass.

Jim

> On Mar 16, 2017, at 4:16 PM, Kamil Rytarowski  wrote:
> 
> On 16.03.2017 22:59, Jim Ingham wrote:
>> But it looks like all the "whole process" events you are talking about are 
>> not stop reasons but more start actions.  That makes sense, but what whole 
>> process stop events do you mean?
> 
> A process can be stopped with a signal. A signal can be emitted to:
> (1) a particular thread,
> (2) the whole process.
> 
> A particular thread can be stopped due to:
> - [PL_EVENT_SIGNAL] being signaled (a signal emitted to the whole
> process or this particular thread)
> - [PL_EVENT_SUSPENDED] being suspended (PT_SUSPEND, _lwp_suspend(2) or
> similar),
> - [PL_EVENT_NONE] no action the whole process stopped, because of a
> sibling thread that was signaled
> 
> If there was no particular thread targeted with a signal we cannot
> retrieve the thread that caused interruption of the process. It differs
> to FreeBSD and Linux as these systems offer always a thread that is
> culprit for interruption. In this scenario we would use "currentthread =
> whole process".
> 
> The GDB Remote Protocol handles it with special thread numbers 0 and -1.
> (I'm not certain what's the exact difference between "all threads" and
> "any thread" in the protocol).
> 
> In my local code, I'm populating all threads within the tracee
> (NativeThread) with exactly the same stop reason - for the "whole
> process" case. I can see - on the client side - that it prints out the
> same message for each thread within the process as all of them captured
> a stop action.
> 
> In Linux, it is possible to trigger multiple stop reasons on each thread
> separately, on NetBSD the first one wins. LLDB offers an extension in
> the GDB Remote Protocol to transfer stop reasons from all threads that
> were stopped due to some occurred event. This is not applicable on
> NetBSD. Faking it, this or that way, can be good enough for the first
> initial and functional port, but there is in my opinion technical dept
> over the port.
> 
> This can be kludged and I can set as the current thread (the one that
> caused interruption) the previously used one or the first one in the list.
> 
> I'm evaluating it from the point of view of a tracee with 10.000 threads
> and getting efficient debugging experience. This is why I would ideally
> reduce NativeThread to a container that is sorted, hashale box of
> integers (lwpid_t) and shut down stopped reason extension called for
> each stopped in debuggee.
> 
> But first things first, I need to make it functional with dummy
> solutions first.
> 
> And yes, I actually want to be able to debug 10.000 LWPs within a debugger.
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

[Kamil Rytarowski via lldb-dev]

On 16.03.2017 22:59, Jim Ingham wrote:
> But it looks like all the "whole process" events you are talking about are 
> not stop reasons but more start actions.  That makes sense, but what whole 
> process stop events do you mean?

A process can be stopped with a signal. A signal can be emitted to:
(1) a particular thread,
(2) the whole process.

A particular thread can be stopped due to:
 - [PL_EVENT_SIGNAL] being signaled (a signal emitted to the whole
process or this particular thread)
 - [PL_EVENT_SUSPENDED] being suspended (PT_SUSPEND, _lwp_suspend(2) or
similar),
 - [PL_EVENT_NONE] no action the whole process stopped, because of a
sibling thread that was signaled

If there was no particular thread targeted with a signal we cannot
retrieve the thread that caused interruption of the process. It differs
to FreeBSD and Linux as these systems offer always a thread that is
culprit for interruption. In this scenario we would use "currentthread =
whole process".

The GDB Remote Protocol handles it with special thread numbers 0 and -1.
(I'm not certain what's the exact difference between "all threads" and
"any thread" in the protocol).

In my local code, I'm populating all threads within the tracee
(NativeThread) with exactly the same stop reason - for the "whole
process" case. I can see - on the client side - that it prints out the
same message for each thread within the process as all of them captured
a stop action.

In Linux, it is possible to trigger multiple stop reasons on each thread
separately, on NetBSD the first one wins. LLDB offers an extension in
the GDB Remote Protocol to transfer stop reasons from all threads that
were stopped due to some occurred event. This is not applicable on
NetBSD. Faking it, this or that way, can be good enough for the first
initial and functional port, but there is in my opinion technical dept
over the port.

This can be kludged and I can set as the current thread (the one that
caused interruption) the previously used one or the first one in the list.

I'm evaluating it from the point of view of a tracee with 10.000 threads
and getting efficient debugging experience. This is why I would ideally
reduce NativeThread to a container that is sorted, hashale box of
integers (lwpid_t) and shut down stopped reason extension called for
each stopped in debuggee.

But first things first, I need to make it functional with dummy
solutions first.

And yes, I actually want to be able to debug 10.000 LWPs within a debugger.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

[Jim Ingham via lldb-dev]

> On Mar 16, 2017, at 2:43 PM, Kamil Rytarowski via lldb-dev 
>  wrote:
> 
> On 16.03.2017 11:55, Pavel Labath wrote:
>> On 16 March 2017 at 00:43, Kamil Rytarowski  wrote:
>>> 
>>> TODO:
>>> - Fixing software breakpoints support,
> 
> Fixed!
> 
> 267->596 of succeeded tests out of 1200+ - please scroll for details.
> 
>>> - Special Registers (Floating Point..) reading/writing,
>>> - Unless it will be too closely related to develop threads - Hardware
>>> watchpoints support in line with the Linux amd64 code,
>>> 
>>> 
>>> As of today the number of passing tests has been degraded. This has been
>>> caused due the fact that LLDB endeavors to set breakpoints in every
>>> process (on the "_start" symbol) - this blocks tracing or simulating
>>> tracing of any process.
>> This is necessary so that we can read the list shared libraries loaded
>> by the process and set any breakpoints in them. Note that currently
>> (at least on Linux) we are doing it actually too late -- at this point
>> the constructors in the shared libraries have already executed, so we
>> cannot set breakpoints or debug the initialization code. I haven't yet
>> investigated how to fix this.
>> 
> 
> I see.
> 
> It's interesting use-case; Right now I'm not sure how properly address it.
> 
> Thank you for your insight.
> 
>> We will need to discuss this in detail. I am not sure removing the
>> NativeThreadNetBSD class completely will is a worthwhile goal, but we
>> can certainly work towards making it's parent class dumber, and remove
>> operations that don't make sense for all users. If e.g. your
>> watchpoints are per-process, then we can pipe watchpoint setting code
>> through NativeProcessProtocol, and NativeProcessNetBSD will implement
>> that directly, while the linux version will delegate to the thread.
>> However, even in your process model each thread has a separate set of
>> registers, so I think it makes sense to keep the register manipulation
>> code there.
>> 
> 
> I put all the threading potential challenges, each one will need to be
> discussed. Refactoring is by definition cost and should be reduced to
> minimum, while getting proper support on the platform. I think
> 
> Our watchpoints (debug registers) are per-thread (LWP) only.
> 
>>> - Support in the current thread function "0" (or "-1" according to the
>>> GDB Remote protocol) to mark that the whole process was interrupted/no
>>> primary thread (from a tracer point of view)
>> Teaching all parts of the debugger (server is not enough, I think you
>> would have to make a lot of client changes as well) about
>> whole-process events might be a big task.
> 
> I think long term this might be useful. I noted in the GDB Remote
> specification that this protocol is embeddable into simulators and
> low-level kernel APIs without regular threads, however it's not urgently
> needed to get aboard for standard user-level debugging facilities; while
> it will be useful in the general set of capabilities in future.
> 
>> I wondering whether you
>> wouldn't make more progress if you just fudged this and always
>> attributed these events to the primary thread. I think we would be in
>> a better position to design this properly once most of the debugger
>> functionality was operational for you.
> 
> Agreed.
> 
> This is why the initial goal of mine is to get as far as possible
> without touching the generic subsystems and get basic threading support.
> 
>> What kind of per-process events
>> are we talking about here?
> 
> I'm mostly thinking about ResumeActions - to resume the whole process,
> while being able single-stepping desired thread(s).
> 
> (We also offer PT_SYSCALL feature, but it's not needed right now in LLDB).
> 
>> Is there anything more here than a signal
>> directed at the whole process?
> 
> single-stepping
> resume thread
> suspend thread
> 
> I'm evaluating FreeBSD-like API PT_SETSTEP/PT_CLEARSTEP for NetBSD. It
> marks a thread for single-stepping. This code is needed to allow us to
> combine PT_SYSCALL & PT_STEP and PT_STEP & emit signal.
> 
> I was thinking about ResumeActions marking which thread to
> resume/suspend/singlestep, whether to emit a signal (one per global
> PT_CONTINUE[/PT_SYSCALL]) and whether to resume the whole thread.
> 
> To some certain point it might be kludged with single-thread model for
> basic debugging.
> 
> 
> I imagined a possible flow of ResumeAction calls like:
> [Generic/Native framework knows upfront the image of threads within
> debuggee]
> - Resume Thread 2 (PT_RESUME)
> - Suspend Thread 3 (PT_SUSPEND)
> - Set single-step Thread 2 (PT_SETSTEP)
> - Set single-step Thread 4 (PT_SETSTEP)
> - Clear single-step Thread 5 (PT_CLEARSTEP)
> - Resume & emit signal SIGIO (PT_CONTINUE)
> 
> In other words: setting properties on threads and pushing the
> PT_CONTINUE button at the end.

I thought about something like this model, that's why all the step commands 
take a thread-id, and why there's a "thread 

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

[Kamil Rytarowski via lldb-dev]

On 16.03.2017 11:55, Pavel Labath wrote:
> On 16 March 2017 at 00:43, Kamil Rytarowski  wrote:
>>
>> TODO:
>>  - Fixing software breakpoints support,

Fixed!

267->596 of succeeded tests out of 1200+ - please scroll for details.

>>  - Special Registers (Floating Point..) reading/writing,
>>  - Unless it will be too closely related to develop threads - Hardware
>> watchpoints support in line with the Linux amd64 code,
>>
>>
>> As of today the number of passing tests has been degraded. This has been
>> caused due the fact that LLDB endeavors to set breakpoints in every
>> process (on the "_start" symbol) - this blocks tracing or simulating
>> tracing of any process.
> This is necessary so that we can read the list shared libraries loaded
> by the process and set any breakpoints in them. Note that currently
> (at least on Linux) we are doing it actually too late -- at this point
> the constructors in the shared libraries have already executed, so we
> cannot set breakpoints or debug the initialization code. I haven't yet
> investigated how to fix this.
> 

I see.

It's interesting use-case; Right now I'm not sure how properly address it.

Thank you for your insight.

> We will need to discuss this in detail. I am not sure removing the
> NativeThreadNetBSD class completely will is a worthwhile goal, but we
> can certainly work towards making it's parent class dumber, and remove
> operations that don't make sense for all users. If e.g. your
> watchpoints are per-process, then we can pipe watchpoint setting code
> through NativeProcessProtocol, and NativeProcessNetBSD will implement
> that directly, while the linux version will delegate to the thread.
> However, even in your process model each thread has a separate set of
> registers, so I think it makes sense to keep the register manipulation
> code there.
> 

I put all the threading potential challenges, each one will need to be
discussed. Refactoring is by definition cost and should be reduced to
minimum, while getting proper support on the platform. I think

Our watchpoints (debug registers) are per-thread (LWP) only.

>>  - Support in the current thread function "0" (or "-1" according to the
>> GDB Remote protocol) to mark that the whole process was interrupted/no
>> primary thread (from a tracer point of view)
> Teaching all parts of the debugger (server is not enough, I think you
> would have to make a lot of client changes as well) about
> whole-process events might be a big task.

I think long term this might be useful. I noted in the GDB Remote
specification that this protocol is embeddable into simulators and
low-level kernel APIs without regular threads, however it's not urgently
needed to get aboard for standard user-level debugging facilities; while
it will be useful in the general set of capabilities in future.

> I wondering whether you
> wouldn't make more progress if you just fudged this and always
> attributed these events to the primary thread. I think we would be in
> a better position to design this properly once most of the debugger
> functionality was operational for you.

Agreed.

This is why the initial goal of mine is to get as far as possible
without touching the generic subsystems and get basic threading support.

> What kind of per-process events
> are we talking about here?

I'm mostly thinking about ResumeActions - to resume the whole process,
while being able single-stepping desired thread(s).

(We also offer PT_SYSCALL feature, but it's not needed right now in LLDB).

> Is there anything more here than a signal
> directed at the whole process?

single-stepping
resume thread
suspend thread

I'm evaluating FreeBSD-like API PT_SETSTEP/PT_CLEARSTEP for NetBSD. It
marks a thread for single-stepping. This code is needed to allow us to
combine PT_SYSCALL & PT_STEP and PT_STEP & emit signal.

I was thinking about ResumeActions marking which thread to
resume/suspend/singlestep, whether to emit a signal (one per global
PT_CONTINUE[/PT_SYSCALL]) and whether to resume the whole thread.

To some certain point it might be kludged with single-thread model for
basic debugging.


I imagined a possible flow of ResumeAction calls like:
[Generic/Native framework knows upfront the image of threads within
debuggee]
 - Resume Thread 2 (PT_RESUME)
 - Suspend Thread 3 (PT_SUSPEND)
 - Set single-step Thread 2 (PT_SETSTEP)
 - Set single-step Thread 4 (PT_SETSTEP)
 - Clear single-step Thread 5 (PT_CLEARSTEP)
 - Resume & emit signal SIGIO (PT_CONTINUE)

In other words: setting properties on threads and pushing the
PT_CONTINUE button at the end.

> AFAICT, most of the stop reasons
> (breakpoint, watchpoint, single step, ...) are still linked to a
> specific thread even in your process model. I think you could get to a
> point where lldb is very useful even without getting these events
> "correct".
> 

I was thinking for example about this change (it's not following the
real function name nor the prototype):

  GetStoppedReason(Thread) -> 

Re: [lldb-dev] Xcode and Pascal (FPC)

[Robinson, Paul via lldb-dev]

I am not an LLDB developer, but based on the symptom you reported,
there are a couple of different possibilities for why it occurs.
One possibility is that FPC up-shifts all the names in the debug info,
but does not add the "case-insensitive" indication.  This would be a
bug in the compiler.
Another is that FPC does add the indication but LLDB is not looking
for it, and always does case-sensitive matching.  This would be a bug 
in LLDB.
In either case it seems there is no good workaround.
--paulr


> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of via
> lldb-dev
> Sent: Thursday, March 16, 2017 1:25 AM
> To: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Xcode and Pascal (FPC)
> 
> Hi,
> 
> I have no answer received yet to this question.
> Maybe this list / forum is not the appropriate place for this kind of
> question.
> 
> If this is the case please advise me to whom I should address myself.
> 
> …or is it just a wast of time to try to improve displaying Pascal variable
> names (not case-sensitive) with the  LLDB Debugger?
> 
> Thanks in advance,
> 
> Best regards,
> 
> Marc
> 
> 
> 
> Van: Marc ROOSE >
> Datum: donderdag 9 maart 2017 13:33
> Aan: "lldb-dev@lists.llvm.org"  d...@lists.llvm.org>
> Onderwerp: Xcode and Pascal (FPC)
> 
> Hi,
> 
> For many years I’m using Xcode to compile and debug source code written in
> Pascal (Free Pascal Compiler).
> Previously using the gdb-debugger.
> 
> With the lldb debugger the "Debug Bar-Proces Controls" and breakpoints
> still works fine.
> Variables values are displayed in the "View variables”.
> Thanks to the LLDB Debugger development team!
> 
> But the Pascal language is not case-sensitive.
> All variable names are displayed in upper case, thus for printing values
> in the “View console output” the variable names has to be typed in upper
> case.
> Consequently copy and past of the variable names from the source editor
> can’t be used.
> Unfortunately also inspecting variables directly in the source editor will
> not work, unless they are typed in upper case.
> 
> Using the lldb-debugger would be much more practical if Pascal variable
> names could be copy/past directly from source editor into the console
> and/or Pascal variables could be inspected directly into the source
> editor.
> 
> Any workaround work around or recommendations how to solve this issue?
> 
> I really appreciate any help someone can provide.
> 
> 
> Marc
> 
> 
> 
> ___
> 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] C++ method declaration parsing

[Pavel Labath via lldb-dev]

I think clang-format's parser would be a better candidate for code
reuse, but even that might be too much, as we don't need that level of
detail (basically we just need to split the name into function name,
return type and argument list), and we can make a lot of simplifying
assumptions here (e.g. template arguments are fully resolved so '>>'
is either two closing template parens, or a part of "operator>>", no
function parameter names or default values, ...).

When you say "recursive descent", you make it sound scary, but is it
really so? AFAICT, the only cause of recursion are the function
pointer return types. Wouldn't that boil down to a single function
that splits out a string into: ()() and
then recurses on 




> A random idea: Instead of parsing demangled C++ method names what people 
> think about writing or reusing a demangler what can gave back both the 
> demangled name and the parsed name in some form?
> My guess is that it would be both more efficient (we already have most of 
> information during demangling) and possibly easier to implement as I expect 
> less edge cases. Additionally I think it would be a nice library to have as 
> part of the LLVM project.

I was originally against that, as it does not solve the full problem,
as I recall sometimes we get names that don't come from a demangler
(e.g. gcc does not bother emitting mangled names in the dwarf for
static functions -- most of the time the mangled name will still be in
the symbol table, but not if the function is inlined, ...). In this
case we need to piece the name together from the dwarf context.
However, now that I think about it, it does not make sense to be
parsing the names that we ourselves have constructed -- we could just
construct the pieces we need from the original source. I think I am
starting to like this idea. It will be more a complicated project than
just fixing the existing parser though...


On 16 March 2017 at 02:42, Eugene Zemtsov via lldb-dev
 wrote:
> Yes, it's a good idea to add cfe-dev.
> It is totally possible that I overlooked something and clang can help with
> this kind of superficial parsing.
>
> As far as I can see even clang-format does it's own parsing
> (UnwrappedLineParser.cpp) and clang-format has very similar need of roughly
> understanding of code without knowing any context.
>
>> are you certain that clang's parser would be unacceptably slow?
>
> I don't have any perf numbers to back it up, but it does look like a lot of
> clang infrastructure needs to be set up before actual parsing begins. (see
> lldb_private::ClangExpressionParser). It's not important though, as at this
> stage I don't see how we can reuse clang at all.
>
>
>
> On Wed, Mar 15, 2017 at 5:03 PM, Zachary Turner  wrote:
>>
>> If there is any way to re-use clang parser for this, it would be
>> wonderful.  Even if it means adding support to clang for whatever you need
>> in order to make it possible.  You mention performance, are you certain that
>> clang's parser would be unacceptably slow?
>>
>> +cfe-dev as they may have some more input on what it would take to extend
>> clang to make this possible.
>>
>> On Wed, Mar 15, 2017 at 4:48 PM Eugene Zemtsov via lldb-dev
>>  wrote:
>>>
>>> Hi, Everyone.
>>>
>>> Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't
>>> cover full extent of possible function declarations,
>>> or even declarations returned by abi::__cxa_demangle.
>>>
>>> Consider this code:
>>> --
>>>
>>> #include 
>>> #include 
>>> #include 
>>>
>>> void func() {
>>>   printf("func() was called\n");
>>> }
>>>
>>> struct Class
>>> {
>>>   Class() {
>>> printf("ctor was called\n");
>>>   }
>>>
>>>   Class(const Class& c) {
>>> printf("copy ctor was called\n");
>>>   }
>>>
>>>   ~Class() {
>>> printf("dtor was called\n");
>>>   }
>>> };
>>>
>>>
>>> int main() {
>>>   std::function f = func;
>>>   f();
>>>
>>>   Class c;
>>>   std::vector v;
>>>   v.push_back(c);
>>>
>>>   return 0;
>>> }
>>>
>>> --
>>>
>>> When compiled It has at least two symbols that currently cannot be
>>> correctly parsed by MethodName::Parse() .
>>>
>>> void std::vector>> >::_M_emplace_back_aux(Class const&)
>>> void (* const::_Any_data::_M_access() const)() - a
>>> template function that returns a reference to a function pointer.
>>>
>>> It causes incorrect behavior in avoid-stepping and sometimes messes
>>> printing of thread backtrace.
>>>
>>> I would like to solve this issue, but current implementation of method
>>> name parsing doesn't seem sustainable.
>>> Clever substrings and regexs are fine for trivial cases, but they become
>>> a nightmare once we consider more complex cases.
>>> That's why I'd like to have code that follows some kind of grammar
>>> describing function declarations.
>>>
>>> As I see it, choices for 

Re: [lldb-dev] C++ method declaration parsing

[Tamas Berghammer via lldb-dev]

A random idea: Instead of parsing demangled C++ method names what people
think about writing or reusing a demangler what can gave back both the
demangled name and the parsed name in some form?

My guess is that it would be both more efficient (we already have most of
information during demangling) and possibly easier to implement as I expect
less edge cases. Additionally I think it would be a nice library to have as
part of the LLVM project.

Tamas

On Thu, Mar 16, 2017 at 2:43 AM Eugene Zemtsov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Yes, it's a good idea to add cfe-dev.
> It is totally possible that I overlooked something and clang can help with
> this kind of superficial parsing.
>
> As far as I can see even clang-format does it's own parsing
> (UnwrappedLineParser.cpp) and clang-format has very similar need of roughly
> understanding of code without knowing any context.
>
> > are you certain that clang's parser would be unacceptably slow?
>
> I don't have any perf numbers to back it up, but it does look like a lot
> of clang infrastructure needs to be set up before actual parsing begins.
> (see lldb_private::ClangExpressionParser). It's not important though, as at
> this stage I don't see how we can reuse clang at all.
>
>
>
> On Wed, Mar 15, 2017 at 5:03 PM, Zachary Turner 
> wrote:
>
> If there is any way to re-use clang parser for this, it would be
> wonderful.  Even if it means adding support to clang for whatever you need
> in order to make it possible.  You mention performance, are you certain
> that clang's parser would be unacceptably slow?
>
> +cfe-dev as they may have some more input on what it would take to extend
> clang to make this possible.
>
> On Wed, Mar 15, 2017 at 4:48 PM Eugene Zemtsov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi, Everyone.
>
> Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't
> cover full extent of possible function declarations,
> or even declarations returned by abi::__cxa_demangle.
>
> Consider this code:
> --
>
> #include 
> #include 
> #include 
>
> void func() {
>   printf("func() was called\n");
> }
>
> struct Class
> {
>   Class() {
> printf("ctor was called\n");
>   }
>
>   Class(const Class& c) {
> printf("copy ctor was called\n");
>   }
>
>   ~Class() {
> printf("dtor was called\n");
>   }
> };
>
>
> int main() {
>   std::function f = func;
>   f();
>
>   Class c;
>   std::vector v;
>   v.push_back(c);
>
>   return 0;
> }
>
> --
>
> When compiled It has at least two symbols that currently cannot be
> correctly parsed by MethodName::Parse() .
>
> void std::vector::_M_emplace_back_aux const&>(Class const&)
> void (* const::_Any_data::_M_access() const)() - a template 
> function that returns a reference to a function pointer.
>
> It causes incorrect behavior in avoid-stepping and sometimes messes
> printing of thread backtrace.
>
> I would like to solve this issue, but current implementation of method
> name parsing doesn't seem sustainable.
> Clever substrings and regexs are fine for trivial cases, but they become a
> nightmare once we consider more complex cases.
> That's why I'd like to have code that follows some kind of grammar
> describing function declarations.
>
> As I see it, choices for new implementation of MethodName::Parse() are
> 1. Reuse clang parsing code.
> 2. Parser generated by bison.
> 3. Handwritten recursive descent parser.
>
> I looked at the option #1, at it appears to be impossible to reuse clang
> parser for this kind of zero-context parsing.
> Especially given that we care about performance of this code. Clang C++
> lexer on the other hand can be reused.
>
> Option #2. Using bison is tempting, but it would require introduction of
> new compile time dependency.
> That might be especially inconvenient on Windows.
>
> That's why I think option #3 is the way to go. Recursive descent parser
> that reuses a C++ lexer from clang.
>
> LLDB doesn't need to parse everything (e.g. we don't care about details
> of function arguments), but it needs to be able to handle tricky return
> types and base names.
> Eventually new implementation should be able to parse signature of every
> method generated by STL.
>
> Before starting implementation, I'd love to get some feedback. It might be
> that my overlooking something important.
>
> --
> Thanks,
> Eugene Zemtsov.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
>
> --
> Thanks,
> Eugene Zemtsov.
> ___
> 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

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

[Pavel Labath via lldb-dev]

On 16 March 2017 at 00:43, Kamil Rytarowski  wrote:
> On 01.03.2017 10:13, Kamil Rytarowski wrote:
>> Hello,
>>
>> The contract for the LLDB port on NetBSD has been prolonged by The
>> NetBSD Foundation. The additional time will cover the features that were
>> delayed in order to address blockers that were unveiled during the work
>> that has been done.
>>
>> I've summarized the newly finished task segment in this blog entry:
>>
>> http://blog.netbsd.org/tnf/entry/ptrace_2_tasks_segment_finished
>>
>> My current plan is to return to LLDB and finish the following tasks:
>>   I. Register context and breakpoints support on NetBSD/amd64.
>
> Halfway point status.
>
> (LLDB developers please check the second part.)
>
> Proper support for breakpoints is all-or-nothing, it's difficult to draw
> firmly the line between "fully functional" and "implemented with bugs".
> Functional software breakpoints are also the next milestone and the goal
> is get tracing a simple 1-threaded program from spawning to its
> termination; correctly and with all the features - as per GDB Remote
> Protocol messages - in line with Linux.
>
> Among the implemented/improved features:
>  - Tracee's .text section disassembling works,
>  - Backtracing (unwinding stack) of the tracee works,
>  - Listing General Purpose and Special Registers works,
>  - Reading General Purpose Registers works,
>  - Setting software breakpoint (placing it into tracee's .text segment)
> works,
>  - Triggering software breakpoint (previously set with a debugger) works,
>  - Rewinding Program Counter and hiding breakpoint from disassembled
> .text section code works,
>  - Scanning tracee's virtual address map works,
>  - Reading Elf Auxiliary Vector (AUXV) works.
>
> What clearly doesn't work is unsetting software breakpoint as the
> debuggee session is crashing afterwards without proper unsetting a trap
> (and the child is killed by the kernel with SIGSEGV). Software
> breakpoints are all-or-nothing, enabling them keeps unveiling bugs in
> code fragments which already appear to work.
>
>
> TODO:
>  - Fixing software breakpoints support,
>  - Special Registers (Floating Point..) reading/writing,
>  - Unless it will be too closely related to develop threads - Hardware
> watchpoints support in line with the Linux amd64 code,
>
>
> As of today the number of passing tests has been degraded. This has been
> caused due the fact that LLDB endeavors to set breakpoints in every
> process (on the "_start" symbol) - this blocks tracing or simulating
> tracing of any process.
This is necessary so that we can read the list shared libraries loaded
by the process and set any breakpoints in them. Note that currently
(at least on Linux) we are doing it actually too late -- at this point
the constructors in the shared libraries have already executed, so we
cannot set breakpoints or debug the initialization code. I haven't yet
investigated how to fix this.

>
>
> Not planned for this segment:
>  - Fixing single step trap - it may automatically get fixed with the
> above features, but it's not the goal for now. This will be part of the
> threads segment.
>  - Everything related to threads and x86 32-bit (i386) support.
>  - Fixing other non-blocker bugs, not related to software breakpoints,
> FPR, debug registers.
>
>
>
>
> My plan for April+ (+ means that it might consume some of May..) is as
> follows:
>  - Alter the design of Resume actions to handle the whole process tasks
> (next to per-thread-ones),
>  - Disable emitting stop reason of all stopped threads in multithreaded
> software on NetBSD as it's not applicable in our thread model (as in
> contrary to Linux),

>  - Alter stopped reason retrieving to ask process (NativeProcess), not
> thread (NativeThread).
>  - Alter watchpoints API to call the process (NativeProcess), not thread
> (NativeThread).
>  - Alter thread type container in process (nativeProcess) to allow to
> use std::set-like containing tid (integers/lwpid_t) to store the current
> image of threads.
We will need to discuss this in detail. I am not sure removing the
NativeThreadNetBSD class completely will is a worthwhile goal, but we
can certainly work towards making it's parent class dumber, and remove
operations that don't make sense for all users. If e.g. your
watchpoints are per-process, then we can pipe watchpoint setting code
through NativeProcessProtocol, and NativeProcessNetBSD will implement
that directly, while the linux version will delegate to the thread.
However, even in your process model each thread has a separate set of
registers, so I think it makes sense to keep the register manipulation
code there.

>  - Support in the current thread function "0" (or "-1" according to the
> GDB Remote protocol) to mark that the whole process was interrupted/no
> primary thread (from a tracer point of view)
Teaching all parts of the debugger (server is not enough, I think you
would have to make a lot of client changes as well) about
whole-process 

[lldb-dev] [Bug 32301] New: LLDB fails to build: readline.cpp:9:31: fatal error: editline/readline.h: No such file or directory

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=32301

Bug ID: 32301
   Summary: LLDB fails to build: readline.cpp:9:31: fatal error:
editline/readline.h: No such file or directory
   Product: lldb
   Version: 4.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: andrewm.robe...@sky.com
CC: llvm-b...@lists.llvm.org

lldb in 4.0.0 release fails to build on Centos 7.3.1611  system.

Scanning dependencies of target readline
[ 17%] Building CXX object
tools/lldb/scripts/Python/modules/readline/CMakeFiles/readline.dir/readline.cpp.o
/home/aroberts/llvm/llvm/tools/lldb/scripts/Python/modules/readline/readline.cpp:9:31:
fatal error: editline/readline.h: No such file or directory
#include 
  ^
compilation terminated.
tools/lldb/scripts/Python/modules/readline/CMakeFiles/readline.dir/build.make:62:
recipe for target
'tools/lldb/scripts/Python/modules/readline/CMakeFiles/readline.dir/readline.cpp.o'
failed
make[2]: ***
[tools/lldb/scripts/Python/modules/readline/CMakeFiles/readline.dir/readline.cpp.o]
Error 1
CMakeFiles/Makefile2:68844: recipe for target
'tools/lldb/scripts/Python/modules/readline/CMakeFiles/readline.dir/all' failed
make[1]: ***
[tools/lldb/scripts/Python/modules/readline/CMakeFiles/readline.dir/all] Error
2
make[1]: *** Waiting for unfinished jobs

I thought this was todo with the requirement for python 3.5, so I installed

yum install devtoolset-6-toolchain devtoolset-6-perftools rh-python35

scl enable devtoolset-6 rh-python35 bash

and retried building and got the same error.

Shouldn't the cmake scripts be checking for python versions, and required
modules etc.

System Details
--

cat /etc/system-release
CentOS Linux release 7.3.1611 (Core) 

uname -a
Linux BlackBox.localdomain 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

scl enable devtoolset-6 rh-python35 bash

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-6/root/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-6/root/usr
--mandir=/opt/rh/devtoolset-6/root/usr/share/man
--infodir=/opt/rh/devtoolset-6/root/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id --enable-plugin
--with-linker-hash-style=gnu --enable-initfini-array --disable-libgcj
--with-default-libstdcxx-abi=gcc4-compatible
--with-isl=/builddir/build/BUILD/gcc-6.2.1-20160916/obj-x86_64-redhat-linux/isl-install
--enable-libmpx --enable-gnu-indirect-function --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.2.1 20160916 (Red Hat 6.2.1-3) (GCC) 

ld -v
GNU ld version 2.27-10.el7

python --version
Python 3.5.1

/usr/local/bin/cmake --version
cmake version 3.7.0

Build Steps:

version=4.0.0

tar -xJf llvm-${version}.src.tar.xz
mv llvm-${version}.src llvm

tar -xJf cfe-${version}.src.tar.xz
mv cfe-${version}.src llvm/tools/clang

tar -xJf clang-tools-extra-${version}.src.tar.xz
mv clang-tools-extra-${version}.src llvm/tools/clang/tools/extra

tar -xJf compiler-rt-${version}.src.tar.xz
mv compiler-rt-${version}.src llvm/projects/compiler-rt

tar -xJf openmp-${version}.src.tar.xz
mv openmp-${version}.src llvm/projects/openmp

tar -xJf libcxx-${version}.src.tar.xz
mv libcxx-${version}.src llvm/projects/libcxx

tar -xJf libcxxabi-${version}.src.tar.xz
mv libcxxabi-${version}.src llvm/projects/libcxxabi

tar -xJf lld-${version}.src.tar.xz
mv lld-${version}.src llvm/tools/lld

tar -xJf polly-${version}.src.tar.xz
mv polly-${version}.src llvm/tools/polly

tar -xJf lldb-${version}.src.tar.xz
mv lldb-${version}.src llvm/tools/lldb

mkdir build
cd build

/usr/local/bin/cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/usr/local/llv
m-${version} -DCMAKE_BUILD_TYPE=Release ../llvm

ncpu=`nproc`
make -j$ncpu

Let me know if you need more info.

Regards

Andrew Roberts

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Xcode and Pascal (FPC)

[via lldb-dev]

Hi,

I have no answer received yet to this question.
Maybe this list / forum is not the appropriate place for this kind of question.

If this is the case please advise me to whom I should address myself.

…or is it just a wast of time to try to improve displaying Pascal variable 
names (not case-sensitive) with the  LLDB Debugger?

Thanks in advance,

Best regards,

Marc



Van: Marc ROOSE >
Datum: donderdag 9 maart 2017 13:33
Aan: "lldb-dev@lists.llvm.org" 
>
Onderwerp: Xcode and Pascal (FPC)

Hi,

For many years I’m using Xcode to compile and debug source code written in 
Pascal (Free Pascal Compiler).
Previously using the gdb-debugger.

With the lldb debugger the "Debug Bar-Proces Controls" and breakpoints still 
works fine.
Variables values are displayed in the "View variables”.
Thanks to the LLDB Debugger development team!

But the Pascal language is not case-sensitive.
All variable names are displayed in upper case, thus for printing values in the 
“View console output” the variable names has to be typed in upper case.
Consequently copy and past of the variable names from the source editor can’t 
be used.
Unfortunately also inspecting variables directly in the source editor will not 
work, unless they are typed in upper case.

Using the lldb-debugger would be much more practical if Pascal variable names 
could be copy/past directly from source editor into the console and/or Pascal 
variables could be inspected directly into the source editor.

Any workaround work around or recommendations how to solve this issue?

I really appreciate any help someone can provide.


Marc



___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 32300] New: Wrong resolving boost::variant template arguments by formatters API

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=32300

Bug ID: 32300
   Summary: Wrong resolving boost::variant template arguments by
formatters API
   Product: lldb
   Version: 3.9
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: andrew.stepano...@gmail.com
CC: llvm-b...@lists.llvm.org

1. Use C++ code:

#include 
#include 
#include 

template
struct Example
{
using Variant = boost::variant;
};

int main()
{
Example::Variant ex(std::string("string"));
Example::Variant ex2(10);
return ex.which() == ex2.which();
}


2. Use formatter for boost::variant:

import lldb
import lldb.formatters.Logger

def get_template_arg(valobj, i):
valobj_type = valobj.GetType().GetUnqualifiedType()
if valobj_type.IsReferenceType():
valobj_type = valobj_type.GetDereferencedType()
if valobj_type.GetNumberOfTemplateArguments() > i:
data_type = valobj_type.GetTemplateArgumentType(i)
else:
data_type = None
return data_type

class BoostVariantSynthProvider:
def __init__(self, valobj, dict):
self.val_obj = valobj
self.value = None
self.update()

def num_children(self):
return 1

def has_children(self):
return True

def get_child_index(self, name):
if name == "value":
return 0

return -1

def get_child_at_index(self, index):
if index == 0:
return self.value

return None

def update(self):
type_index =
self.val_obj.GetChildMemberWithName("which_").GetValueAsUnsigned()
element_type = get_template_arg(self.val_obj, type_index)
self.value =
self.val_obj.GetChildMemberWithName("storage_").GetChildMemberWithName("data_").
\
GetChildMemberWithName("buf").CreateChildAtOffset("value", 0,
element_type)

Actual:
GetNumberOfTemplateArguments() returns 1 for Example::Variant type and
get_template_arg returns 'None'
Expected:
GetNumberOfTemplateArguments() should return 3 for Example::Variant type
and get_template_arg should returns std::string type

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev