Re: [lldb-dev] showing CPU register flags

[Jim Ingham via lldb-dev]

We've talked about providing a more natural view of registers that are 
logically made of subfields, as you describe, but I don't think any work has 
been done on that front.

The ValueObjectRegister has a couple of ways to implement this display.  The 
ValueObjectRegisters can be given a type, and then will display the subfields 
as though they were of that type.  So you could cons up synthetic types for 
your registers, and use that to display them.  The other way would be to use 
the synthetic child mechanism for ValueObjects in general, would be pretty 
amenable to this sort of re-presentation.  Another slightly tricky bit would be 
that if you showed a register as having "sub-fields" folks would probably 
assume they could use these for "register write" as well are "register read".  
I don't think the synthetic children can be used to change values of the 
ValueObject that produced them.  But if you gave them a synthetic type instead, 
that might just fall out.

The other concern is that the "register read" command uses a lower level 
interface (RegisterValues) rather than using ValueObjectRegister's.  The 
RegisterValues really want to be scalars, so they don't provide a natural way 
to do this.  You would probably have to convert "register read" over to use the 
ValueObject for this project to be worth doing.

Jim


> On Aug 17, 2016, at 8:17 AM, Giusti, Valentina via lldb-dev 
>  wrote:
> 
> Hi everyone,
> 
> I am currently implementing the support for the Intel MPX registers in LLDB. 
> This register set includes 2 registers, BNDSTATUS and BNDCFGU, which store 
> information about the status and configuration of the MPX feature in several 
> fields.
> I think that it would be useful for the user to have a nice display of such 
> fields, so that they don't have to extract the information from the raw 
> values of the registers. However, I see that the other registers are just 
> displayed as raw values, without any better ways to explore their contents.
> 
> Should I just follow this approach, and also just let the MPX registers be 
> available through their raw values? 
> Or have there ever been any requests for ways to display the register flags 
> from LLDB?
> 
> Thanks,
> - Valentina Giusti
> 
> 
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
> 
> ___
> 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] Code Coverage with GCOV

[Vedant Kumar via lldb-dev]

Is it possible that the files are written to an unexpected directory? Have you
tried running the program under strace/dtruss to conclusively determine whether
or not the files are being written? Could you try running lldb-server in lldb
and setting a breakpoint on `llvm_gcda_start_file'?

vedant

> On Aug 17, 2016, at 3:50 AM, Ravitheja Addepally  
> wrote:
> 
> Hello,
>I added the following lines to the lldb-server and lldb CMakeLists.txt
>set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fprofile-arcs -ftest-coverage")
>set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fprofile-arcs 
> -ftest-coverage")
> 
> I am able to get the lldb-server gcov files when I start its instance and 
> then connect to it. But since lldb starts the lldb-server in different way, 
> the files are not written, because I do see that the gcov instrumentation 
> functions are present in the lldb-server.
> 
> Best Regards,
> A Ravi Theja
> 
> On Tue, Aug 16, 2016 at 7:27 PM, Vedant Kumar  wrote:
> Hi Ravitheja,
> 
> Could you show us the diff to your cmake configuration? You may want to take a
> look at how the LLVM_BUILD_INSTRUMENTED cmake option is implemented to
> double-check that you've got something reasonable (see: llvm/CMakeLists.txt 
> and
> cmake/modules/HandleLLVMOptions.cmake).
> 
> Also, you may want to double-check that the gcda files are being written to 
> the
> right directory.
> 
> best,
> vedant
> 
> 
> > On Aug 16, 2016, at 7:58 AM, Ravitheja Addepally via lldb-dev 
> >  wrote:
> >
> > Hello,
> >I was trying to get Code Coverage for LLDB with GCOV on Linux by 
> > adding the corresponding flags in the CMake files, but I am facing problem 
> > with lldb-server, which does not give seem to generate the gcda files. The 
> > host side does generate the gcov files although. The lldb-server does 
> > generate the gcov files if it is started in Standalone mode but it does not 
> > generate the gcov files if started by LLDB. Has anyone tried this already ? 
> > How can I get Code Coverage for lldb / lldb-server on Linux ?
> >
> >
> > Best Regards,
> > A Ravi Theja
> > ___
> > 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] Code Coverage with GCOV

[Ravitheja Addepally via lldb-dev]

Hello,
   I added the following lines to the lldb-server and lldb
CMakeLists.txt
   set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fprofile-arcs -ftest-coverage")
   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fprofile-arcs
-ftest-coverage")

I am able to get the lldb-server gcov files when I start its instance and
then connect to it. But since lldb starts the lldb-server in different way,
the files are not written, because I do see that the gcov instrumentation
functions are present in the lldb-server.

Best Regards,
A Ravi Theja

On Tue, Aug 16, 2016 at 7:27 PM, Vedant Kumar  wrote:

> Hi Ravitheja,
>
> Could you show us the diff to your cmake configuration? You may want to
> take a
> look at how the LLVM_BUILD_INSTRUMENTED cmake option is implemented to
> double-check that you've got something reasonable (see:
> llvm/CMakeLists.txt and
> cmake/modules/HandleLLVMOptions.cmake).
>
> Also, you may want to double-check that the gcda files are being written
> to the
> right directory.
>
> best,
> vedant
>
>
> > On Aug 16, 2016, at 7:58 AM, Ravitheja Addepally via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hello,
> >I was trying to get Code Coverage for LLDB with GCOV on Linux by
> adding the corresponding flags in the CMake files, but I am facing problem
> with lldb-server, which does not give seem to generate the gcda files. The
> host side does generate the gcov files although. The lldb-server does
> generate the gcov files if it is started in Standalone mode but it does not
> generate the gcov files if started by LLDB. Has anyone tried this already ?
> How can I get Code Coverage for lldb / lldb-server on Linux ?
> >
> >
> > Best Regards,
> > A Ravi Theja
> > ___
> > 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] Breakpoint + callback performance ... Can it be faster?

[Pavel Labath via lldb-dev]

Hello Benjamin, all,

the lldb-server implementation in linux works exactly the same way as
debugserver does on osx -- it runs out of process and uses sockets to
communicate with the client. The socketpair() optimization that Jim is
talking about is not enabled there yet - I want to do some benchmarks
first to make sure it really helps. Feel free to try it out if you
want, I'd be very interested in hearing the results (the relevant
commit is r278524). However, I doubt it will make enough difference to
make your use case work.

Moving the debugging code into the same process could easily make
things an order of magnitude faster and it _might_ be enough for your
purposes, but it's an extremely non-trivial task. I think doing that
would be a great idea, but I would expect a serious commitment to
maintaining and testing that path from whoever wanted to do that.

cheers,
pl


On 16 August 2016 at 21:43, Benjamin Dicken via lldb-dev
 wrote:
>
>
> On Tue, Aug 16, 2016 at 11:06 AM, Jim Ingham  wrote:
>>
>>
>> > On Aug 16, 2016, at 10:42 AM, Benjamin Dicken
>> >  wrote:
>> >
>> > Thanks for the quick reply.
>> >
>> > > Are you sure the actual handling of the breakpoint & callback in lldb
>> > > is what is taking most of the time?
>> >
>> > I'm not positive. I did collect some callgrind profiles to take a look
>> > at where most of the time is being spent, but i'm not very familiar with
>> > lldb internals so the results were hard to interpret. I did notice that
>> > there was a lot of packet/network business when using lldb to profile a
>> > program (which I assumed was communication between my program and
>> > lldb-server). I was not sure how this effected the performance, so perhaps
>> > this is the real bottleneck.
>>
>> I would be pretty surprised if it was not.  We had some bugs in breakpoint
>> handling - mostly related to having very very many breakpoints.  But other
>> than that the dispatching of the breakpoint StopInfo is a pretty simple,
>> straight forward bit of work.
>>
>> >
>> > > Greg just switched to using a unix-domain socket for this
>> > > communication for platforms that support it.  This speeds up the packet
>> > > traffic side of things.
>> >
>> > In what version of lldb was this introduced? I'm running 3.7.1. I'm also
>> > on ubuntu 14.04, is that a supported platform?
>>
>> It is just in TOT lldb, he just added it last week.  It is currently only
>> turned on for OS X.
>
>
> Good to know, thanks.
>>
>>
>> >
>> > > One of the original motivations of having lldb-server be based on lldb
>> > > classes - as opposed to the MacOS X version of debugserver which is an
>> > > independent construct - was that you could re-use the server code to 
>> > > create
>> > > an in-process Process plugin, eliminating a lot of this traffic & context
>> > > switching when you needed maximum speed.
>> >
>> > That sounds very interesting. Is there an example of this implementation
>> > you could point me to?
>> >
>>
>> FreeBSB & Windows still have native Process plugins.  But they aren't used
>> for the lldb-server implementation so far as I can tell (I've mostly worked
>> on the OS X side.)  I think this was more of a design intent that hasn't
>> actually been used anywhere yet.  But the Linux/Android folks will know
>> better.
>
>
> If any of the Linux/Andriod folks do know, please get in touch with me.
> Thanks,
>
>>
>> Jim
>>
>>
>> >
>> >
>> > On Tue, Aug 16, 2016 at 10:20 AM, Jim Ingham  wrote:
>> > Are you sure the actual handling of the breakpoint & callback in lldb is
>> > what is taking most of the time?  The last time we looked at this, the
>> > majority of the work was in communicating with debugserver to get the stop
>> > notification and restart.  Note, besides all the packet code, this involves
>> > context switches from process->lldbserver->lldb and back, which is also
>> > pretty expensive.
>> >
>> > Greg just switched to using a unix-domain socket for this communication
>> > for platforms that support it.  This speeds up the packet traffic side of
>> > things.
>> >
>> > One of the original motivations of having lldb-server be based on lldb
>> > classes - as opposed to the MacOS X version of debugserver which is an
>> > independent construct - was that you could re-use the server code to create
>> > an in-process Process plugin, eliminating a lot of this traffic & context
>> > switching when you needed maximum speed.  The original Mac OS X lldb port
>> > actually had a process plugin wholly in-process with lldb as well as the
>> > debugserver based one, but there wasn't enough motivation to justify
>> > maintaining the two different implementations of the same code.  I don't
>> > know whether the Linux port takes advantage of this possibility, however.
>> > That would be something to look into, however.
>> >
>> > Once we actually figure out about the stop, figuring out the breakpoint
>> > and getting to 

Re: [lldb-dev] Search C++ "virtual" objects

[Lei Kong via lldb-dev]

I’d like to add FindSymbolsByRegex, please let me know what I need to do.
Thanks.

Sent from Mail for Windows 10

From: Greg Clayton
Sent: Tuesday, August 16, 2016 11:42 AM
To: Lei Kong
Cc: Lei Kong via lldb-dev
Subject: Re: [lldb-dev] Search C++ "virtual" objects


> On Aug 15, 2016, at 4:59 PM, Lei Kong  wrote:
>
> Should I use lldb::SBTarget::GetModuleAtIndex() to get all modules and then 
> lldb::SBModule::GetSymbolAtIndex() to go through all symbols?
> Thanks.

This is the only way right now as we don't have a SBModule::FindSymbols that 
takes a regular expression. We only currently have:

lldb::SBSymbolContextList
FindSymbols (const char *name,
 lldb::SymbolType type = eSymbolTypeAny);


If you want to, you can add a:


lldb::SBSymbolContextList
FindSymbolsByRegex (const char *regex, lldb::SymbolType type = 
eSymbolTypeAny);


Then you could call this:


SBModule module = ...;
lldb::SBSymbolContextList symbols = module.FindSymbolsByRegex("^vtable for ");


You can then also add this to SBTarget. Let me know if you are interested in 
adding this and I can help you do it.

Greg Clayton


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