Re: [lldb-dev] add custom vendor commands

[Giusti, Valentina via lldb-dev]

> On Oct 18, 2016, at 6:43 PM, Clayton, Greg  wrote:
>
> > On Oct 18, 2016, at 7:48 AM, Giusti, Valentina 
> wrote:
> >
> > Hi Greg,
> >
> > Thanks a lot for your reply, please find below my answers.
> >
> >> You can install new python commands that can do the job to work out
> >> the details.
> >>
> >> http://lldb.llvm.org/python-reference.html
> >>
> >> See the section named "CREATE A NEW LLDB COMMAND USING A PYTHON
> >> FUNCTION".
> >>
> >> You can basically install a new "intel" command and parse all of the
> >> options "show mpx-bounds ..." or "set mpx-bounds ..." from within this new
> command.
> >> You can use the public LLDB API to look through the process and do
> >> things. Let me know if you need any help with this. There is also a
> >> API to add custom commands from C++ plug-ins. Enrico Granata did this
> >> work and can answer more questions on that. Either way, both commands
> >> (python and C++ plug-ins) have access to the public API for LLDB, so
> >> the code you will write will use the same API. So I would stick with 
> >> python for
> now to get things working.
> >>
> >
> > I think I would rather start right away with the C++ approach. If I 
> > understand
> correctly, it means to create a specific Intel plugin under the directory
> source/Plugins and use the LLDB API to add the custom command.
> 
> That is one way to do this, but any change you make will require a recompile 
> of
> LLDB.
> 
> The only external plug-ins we currently have with LLDB are for adding
> commands. See the following code in our test suite where $(trunk) is the root 
> of
> your LLDB checkout:
> 
> $(trunk)/packages/Python/lldbsuite/test/functionalities/plugins/commands
> 
> This show you how to compile a C++ plug-in that will be loaded by LLDB if it 
> is
> placed in the right plug-in location.  So this would allow you to distribute 
> a plug-
> in that can work with existing released LLDB in case you care to do so.
> 

Thanks for mentioning this, I will keep it in mind. However I think I prefer to 
implement a builtin command.

> >
> >> Some questions for you:
> >> - How do plan on detecting that you have an intel processor?
> >
> > I thought of checking if the target architecture is either 
> > llvm::Triple::x86 or
> llvm::Triple::x86_64. Do you think there is a better approach to this?
> 
> I guess just checking for the "BNDCFGU" register is what you will need to do?
> 

Yeah, I can probably skip the arch checking step.

> >
> >> - Do you need access to any process registers? If so, are these
> >> registers thread specific? Are these registers available currently on 
> >> linux and
> MacOS?
> >
> > I only need to access the MPX configuration register, BNDCFGU. As far as I
> know, MacOS doesn't have MPX support, so I also didn't implement the MPX
> support for MacOS in LLDB, which means it is only available in Linux at the
> moment.
> >
> >> - How do you locate the BT? (or do you even need to?). Is there
> >> symbol? Can you extract all values in the bounds table once you locate it?
> >>
> >
> > The bound tables are allocated contiguously in the process memory, starting
> from the Bound Directory address which is stored in the BNDCFGU register.
> Therefore, in the plugin I only need to access this register, do the 
> appropriate
> calculations and then access the process memory to get the requested bound
> table entry.
> 
> Great. This sounds easy to do. Just decide if you prefer a built in command 
> or to
> create an external command shared library plug-in and you are all set to go!
> 

Seems so, thanks!

- Val

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] add custom vendor commands

[Giusti, Valentina via lldb-dev]

Hi Greg,

Thanks a lot for your reply, please find below my answers.

> You can install new python commands that can do the job to work out the
> details.
> 
> http://lldb.llvm.org/python-reference.html
> 
> See the section named "CREATE A NEW LLDB COMMAND USING A PYTHON
> FUNCTION".
> 
> You can basically install a new "intel" command and parse all of the options
> "show mpx-bounds ..." or "set mpx-bounds ..." from within this new command.
> You can use the public LLDB API to look through the process and do things. Let
> me know if you need any help with this. There is also a API to add custom
> commands from C++ plug-ins. Enrico Granata did this work and can answer
> more questions on that. Either way, both commands (python and C++ plug-ins)
> have access to the public API for LLDB, so the code you will write will use 
> the
> same API. So I would stick with python for now to get things working.
> 

I think I would rather start right away with the C++ approach. If I understand 
correctly, it means to create a specific Intel plugin under the directory 
source/Plugins and use the LLDB API to add the custom command. 

> Some questions for you:
> - How do plan on detecting that you have an intel processor?

I thought of checking if the target architecture is either llvm::Triple::x86 or 
llvm::Triple::x86_64. Do you think there is a better approach to this?

> - Do you need access to any process registers? If so, are these registers 
> thread
> specific? Are these registers available currently on linux and MacOS?

I only need to access the MPX configuration register, BNDCFGU. As far as I 
know, MacOS doesn't have MPX support, so I also didn't implement the MPX 
support for MacOS in LLDB, which means it is only available in Linux at the 
moment.

> - How do you locate the BT? (or do you even need to?). Is there symbol? Can
> you extract all values in the bounds table once you locate it?
> 

The bound tables are allocated contiguously in the process memory, starting 
from the Bound Directory address which is stored in the BNDCFGU register. 
Therefore, in the plugin I only need to access this register, do the 
appropriate calculations and then access the process memory to get the 
requested bound table entry.

- Val 

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] add custom vendor commands

[Giusti, Valentina via lldb-dev]

Hello all,

Background: 
Intel CPUs that support MPX have a limited number of bound registers. For any 
program that has more objects than fit into these registers, the bounds must be 
kept elsewhere. For this purpose, Bounds Tables (BT) are stored in application 
memory: for each pointer there is a bound table entry with lower bound, upper 
bound, check pointer value.

It would be convenient for the user to be able to access the BT and possibly 
also manipulate it, through commands like: 'set/show mpx-bounds  
 '.

Is there a way to add customized commands for vendor features, such as this one?
I have seen that CommandObjectCommands has a class to add commands interpreted 
by command interpreter scripts and an interface for command aliases, so I 
wonder if it would make sense to add something else for vendor commands. For 
example, I could create a new class CommandObjectVendor that allows vendors to 
create their own specific commands. In my case, for the MPX bound table, the 
commands could be:

intel show mpx-bounds   

intel set mpx-bounds


Thanks in advance for your help,

- V.


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] showing CPU register flags

[Giusti, Valentina via lldb-dev]

Thanks for your replies!

@Greg, I think I will start by trying your approach and then I will get back to 
you with some feedback in a couple of days.

Cheers,
- Valentina

> -Original Message-
> > 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
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