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

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 its callback is pretty simple...  I doubt making "lighter
>> > weight breakpoints" in particular

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

[lldb-dev] showing CPU register flags

[Giusti, Valentina via lldb-dev]

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

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] 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] Search C++ "virtual" objects

[Greg Clayton via lldb-dev]

You should add it to both SBModule and SBTarget.

To add new APIs you need to:

- add function prototype to include/lldb/API/SBModule.h and 
include/lldb/API/SBTarget.h
- add function body to source/API/SBModule.cpp and source/API/SBTarget.cpp
- add function prototype to Swig interface files scripts/interface/SBModule.i 
and scripts/interface/SBTarget.h
- add test that tests both new interfaces in the 
"packages/Python/lldbsuite/test/python_api" directory by creating a new 
directory named something appropriate. You can start by copying the "event" 
directory in there to "symbol_regex" and then rename the test python file to 
SymbolRegex.py. And add a test the compiles a C++ file with a few virtual 
classes and then search use your new APIs and make sure they work as expected.

The function prototypes will be:

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

And

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

The module version will search the module in the SBModule object only, and the 
SBTarget version will use the module list found in the target object.

Greg


> On Aug 17, 2016, at 12:24 AM, Lei Kong  wrote:
> 
> 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

Re: [lldb-dev] showing CPU register flags

[Greg Clayton via lldb-dev]

> 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?

We haven't done anything fancy for registers yet. I see a few ways to do this:

1 - allow register values to specify a CompilerType as the way to display the 
register. Right now registers always default to use simple built in types:


CompilerType
ValueObjectRegister::GetCompilerTypeImpl ()
{
if (!m_compiler_type.IsValid())
{
ExecutionContext exe_ctx (GetExecutionContextRef());
Target *target = exe_ctx.GetTargetPtr();
if (target)
{
Module *exe_module = target->GetExecutableModulePointer();
if (exe_module)
{
TypeSystem *type_system = exe_module->GetTypeSystemForLanguage 
(eLanguageTypeC);
if (type_system)
m_compiler_type = 
type_system->GetBuiltinTypeForEncodingAndBitSize (m_reg_info.encoding,

 m_reg_info.byte_size * 8);
}
}
}
return m_compiler_type;
}


so we currently take the encoding and byte size and make a built in type for 
it. We could allow a RegisterContext to manually create types using for a given 
target. 

We might allow RegisterInfo structs to have an extra field that is expression 
text that defines a register type something like:

const char *my_register_type = "typedef enum EnumType { eValueA, eValueB, 
eValueC}; struct reg_type { uint8_t a : 7, b:2, c:2; EnumType enum; }"

Then we could use the top level expression parser to parse the expression and 
extract the "reg_type" as a CompilerType from the source code. Then you could 
define any type you want for your register. Sean Callanan will be able to help 
with expression parser details if this sounds like something you would like to 
do. I can help with the rest of the plumbing. 

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