Re: [lldb-dev] Symbolicate user processes when kernel debugging
> "I want a GDB server port for user space process 123" How would I start this gdb server? Do you mean a gdb-server running in the target userspace? Wouldn't that make impossible to use it when the kernel is stopped? I tried searching around and the only resources I found is this old macros file for gdb (http://opensource.apple.com/source/xnu/xnu-1456.1.26/kgmacros) that had a switchtouserthread command that seems to do something similar to what I want to achieve. (but obviously I want to use lldb so that doesn't apply, also I'm not sure it would work since it is pretty old). The other interesting file I found is https://opensource.apple.com/source/xnu/xnu-3247.1.106/tools/lldbmacros/usertaskgdbserver.py?txt that has a beginusertaskdebugging that from the description seems to do what you were describing, but strangely it doesn't seem to be available/implemented? John Otter 2016-06-21 0:57 GMT+02:00 Greg Clayton : > The right way to do this is to say "I want a GDB server port for user space > process 123". The python would then start up a socket that can be connected > to that can vend the information about the user space process directly > through a dedicated GDB server port. Memory reads would translate the memory > asked for through the GDB server port into a physical address and do the read > for you as if the memory read came from user space process 123. I know > someone had this code working here at Apple, but I am not sure if it made it > into the macros. You might check around for such a thing as it might already > be in there. Then you can also read memory and read registers just as you > would with a core file. Then you can skip all of the manual symbolication > stuff as the process will set itself up correctly if the GDB server is > responding to all the right questions. > > So check around and make sure this isn't already checked into the code. > > Greg Clayton >> On Jun 16, 2016, at 1:38 AM, John Otter via lldb-dev >> wrote: >> >> I'm using lldb to debug the OS X kernel, and it works great. >> I would like to have more flexibility in analysing user programs while >> debugging the kernel itself, >> and specifically symbolicate the code of the user programs. >> >> For example I often use the command showthreaduserstack defined here >> http://opensource.apple.com//source/xnu/xnu-2422.1.72/tools/lldbmacros/userspace.py >> to take >> a look at the user stack of a process running in kernel mode that just >> scripts the process of >> obtaining the thread saved state, but the output unfortunately isn't >> symbolicated. >> >> Is there a way to add symbols for a user process (programs and shared libs?) >> I looked into the target modules add command, but when I try to add a >> copy of the executable >> it just says that the file I pick doesn't exist (even though it clearly >> exist). >> Also I'm not entirely sure how that would work since the user space >> addressing space changes >> for every process, even if I manually set the loading address. >> Would that work only for that specific process and execution? >> >> Regards, >> John >> ___ >> 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] GetSymbolContext(lldb.eSymbolContextEverything)
Thanks a lot Greg for your input. I have tried the 2nd option to parse the
out of image lookup command and it works perfectly fine for me.
Regards,
Kamenee
On Tue, Jun 21, 2016 at 2:21 PM, Greg Clayton wrote:
> We currently don't expose this information through the API, though we
> could. You could add a new method to SBValue:
>
> namespace lldb
> {
> class SBValue
> {
> SBData GetDWARFLocation();
> }
> };
>
> This could return the DWARF location as a SBData object. Then you could
> consume the data by parsing the DWARF DW_OP enumerations. Otherwise you can
> parse the textual output of the "image lookup -va 0x123" command:
>
> result = lldb.SBCommandReturnObject()
> ci = debugger.GetCommandInterpreter()
> ci.HandleCommand("image lookup -va %#x" % (frame.GetPC()), result, False)
>
> # Now all output from the above command is in "result"
> output = result.GetOutput()
>
> # Parse "output" for variable locations
>
>
>
>
> > On Jun 21, 2016, at 9:07 AM, Kamenee Arumugam
> wrote:
> >
> > Hi Greg,
> >
> > Thanks for your reply. I did try the method you mention above but
> variable.GetLocation() only provide me the memory address of the variable.
> What exactly I am looking for was the register offset that stores variable
> i here. Example, I am looking for method able to output the one highlighted
> in yellow:
> >
> > Variable: id = {0x00a2}, name = "i", type= "int", location =
> DW_OP_fbreg(-564), decl = ivm_demo.c:6
> >
> >
> > Basically, I am working on a binary instrumentation research tool, that
> will inject code to check changes on selected variable. Therefore, using
> register offset, I am able to inject check for instruction using this
> register with this offset.
> > Please let me know if you have any better method to grab register offset
> for particular variable.
> >
> > Thanks,
> > Kamenee
> >
> > On Mon, Jun 20, 2016 at 7:15 PM, Greg Clayton
> wrote:
> > The variables are available through the frame in your symbol context.
> You have a line of code commented out in your script:
> >
> > #variable = frame.GetVariables(target,True,True,True)
> >
> > Change it to:
> >
> > get_arguments = True # Get argument variables
> > get_locals = True # Get local variables
> > get_statics = True # Get globals and static variables
> > get_in_scope_only = True # only get variables that are in scope
> > use_dynamic = lldb.eDynamicDontRunTarget # Get dynamic types for
> variables
> > variables = frame.GetVariables (get_arguments, get_locals, get_statics,
> get_in_scope_only, use_dynamic)
> > print variables
> >
> > This output will look different from the output in "image lookup
> --address 0x... --verbose" because we have an actual frame here so we can
> dump the variable value itself because we have a stack frame that allows us
> to have variable values. If you want the location of the variable you can
> also print that in a for loop using "variables" from above:
> >
> > for variable in variables:
> > print str(variable)
> > print "Location = %s" % (variable.GetLocation())
> >
> >
> > Each "variable" object is a lldb.SBValue type. There are many API calls
> on these that you can call manually depending on what you want. Let me know
> if you have any questions.
> >
> > Greg Clayton
> >
> >
> >
> >
> > > On Jun 17, 2016, at 11:34 AM, Kamenee Arumugam via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > >
> > > Hi,
> > >
> > > I am trying program using Lldb Python API to get an output exactly
> same when I run this command "image lookup --address 0x000405a6
> --verbose". But when I print return value of
> GetSymbolContext(lldb.eSymbolContextEverything), it doesnt contain the
> decoding of local variables which the above commands can print out local
> variables.
> > >
> > > I have attached a simple script.py that I have developed. It is not
> possible to print out local variables using the APIs or I am missing
> something out?
> > >
> > > I am looking forward to hear from you soon.
> > >
> > > Thanks,
> > > kmn
> > > ___
> > > 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] Variable shadowing
Hi all,
I'm using lldb 3.9 through the C++ API and I'm trying to determine if a local
variable is shadowed or not with no luck.
For the code below:
1. Is there an API call, that I somehow missed, that can tell me that (v
= 2) shadows (v = 1)?
2. Can I rely on their order in the SBValueList object?
3. Would you guys think it would be worth adding bool
SBValue::IsShadowed() const ?
1 void foo()
2 {
3 int v = 1;
4 {
5 int v = 2;
--> 6 ++v;
7 }
8 }
Thank,
Bogdan
National Instruments Romania S.R.L.
--
B-dul 21 Decembrie 1989, nr. 77, A2
Cluj-Napoca 400604, Romania
C.I.F.: RO17961616 | O.R.C.: J12/3337/2005
Telefon: +40 264 406428 | Fax: +40 264 406429
E-mail: office.c...@ni.com
Web: romania.ni.com
Vanzari si suport tehnic:
Telefon gratuit : 0800 070071
E-mail vanzari: ni.roma...@ni.com
E-mail suport tehnic: techsupp...@ni.com
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Remote debugging - unix socket and/or specific port
Hi, I’ve been trying to run lldb-server from within a linux container lately. When I try to attach from outside the container using lldb command, most steps are successful but I can’t launch the process: platform select remote-linux 👍 platform connect connect://IP:PORT 👍 target create main 👍 process launch ❌ My guess is that the container only exposes the control port, the one I’m listening to with lldb-server p --listen *:PORT. And it seems that ports are dynamically allocated to then handle process debugging. I don’t want my container to expose too many ports, as I usually have in fact only one debuggable process running inside. (I tried, I can launch my process if the container exposes all ports) Is there a way to set a range for these dynamically allocated ports using lldb-server? I can’t find it in the docs, and help command can’t help me either: Usage: lldb-server p [--log-file log-file-name] [--log-channels log-channel-list] [--port-file port-file-path] --server --listen port Also, is there an option to use unix sockets instead of ports? Thanks for your help! - Adrien Duermael ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] lldb mutex debugging command
Dear all you know, in windbg there is a very useful command -- locks . it will tell us who owned the special lock. in lldb, there is no such command. sometimes, we have a deadlock. but we cannot find the mutex, whitch thread owned it , and do not release!! Thank you very much!___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] lldb mutex debugging command
Dear all you know, in windbg there is a very useful command -- locks . it will tell us who owned the special lock. in lldb, there is no such command. sometimes, we have a deadlock. but we cannot find the mutex, whitch thread owned it , and do not release!! Thank you very much!___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Remote debugging - unix socket and/or specific port
Hi, I’ve been trying to run lldb-server from within a linux container lately. When I try to attach from outside the container using lldb command, most steps are successful but I can’t launch the process: platform select remote-linux 👍 platform connect connect://IP:PORT 👍 target create main 👍 process launch ❌ My guess is that the container only exposes the control port, the one I’m listening to with lldb-server p --listen *:PORT. And it seems that ports are dynamically allocated to then handle process debugging. I don’t want my container to expose too many ports, as I usually have in fact only one debuggable process running inside. (I tried, I can launch my process if the container exposes all ports) Is there a way to set a range for these dynamically allocated ports using lldb-server? I can’t find it in the docs, and help command can’t help me either: Usage: lldb-server p [--log-file log-file-name] [--log-channels log-channel-list] [--port-file port-file-path] --server --listen port Also, is there an option to use unix sockets instead of ports? Thanks for your help! - Adrien Duermael___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Symbolicate user processes when kernel debugging
> On Jun 22, 2016, at 3:38 AM, John Otter wrote: > >> "I want a GDB server port for user space process 123" > > How would I start this gdb server? Do you mean a gdb-server running in > the target userspace? Wouldn't that make impossible to use it when the > kernel is stopped? No, the python script that is debugging the kernel would make a socket on a new port and hand that out. It is very easy to write a GDB server in python. Each connection would know what user space process it is answering questions for. For example we say "create GDB server for process 123" and we create a GDBServerPython class and give it user space process 123. When the connection asks about the threads in the process, it would read the threads from the kernel data structures and return the info on the threads for user space process 123. If memory is requested like "memory read 0x1000 --count 256", you would look through the TLB entries in the kernel, map "0x1000" to a physical address, and return the correct bytes for that memory read. When registers for a given thread are requested, you would find the thread data structure in kernel memory for the thread and return the correct registers. That is enough to fake a user space connection to a user space process. > > I tried searching around and the only resources I found is this old > macros file for gdb > (http://opensource.apple.com/source/xnu/xnu-1456.1.26/kgmacros) that > had a switchtouserthread command that seems to do something similar to > what I want to achieve. (but obviously I want to use lldb so that > doesn't apply, also I'm not sure it would work since it is pretty > old). > The other interesting file I found is > https://opensource.apple.com/source/xnu/xnu-3247.1.106/tools/lldbmacros/usertaskgdbserver.py?txt > that has a beginusertaskdebugging that from the description seems to > do what you were describing, but strangely it doesn't seem to be > available/implemented? I looked into it and we have a solution that does this internally at Apple, but it isn't in the public XNU LLDB macros. I will check if they are willing to give out any details on this so others could use it. Greg clayton > John Otter > > 2016-06-21 0:57 GMT+02:00 Greg Clayton : >> The right way to do this is to say "I want a GDB server port for user space >> process 123". The python would then start up a socket that can be connected >> to that can vend the information about the user space process directly >> through a dedicated GDB server port. Memory reads would translate the memory >> asked for through the GDB server port into a physical address and do the >> read for you as if the memory read came from user space process 123. I know >> someone had this code working here at Apple, but I am not sure if it made it >> into the macros. You might check around for such a thing as it might already >> be in there. Then you can also read memory and read registers just as you >> would with a core file. Then you can skip all of the manual symbolication >> stuff as the process will set itself up correctly if the GDB server is >> responding to all the right questions. >> >> So check around and make sure this isn't already checked into the code. >> >> Greg Clayton >>> On Jun 16, 2016, at 1:38 AM, John Otter via lldb-dev >>> wrote: >>> >>> I'm using lldb to debug the OS X kernel, and it works great. >>> I would like to have more flexibility in analysing user programs while >>> debugging the kernel itself, >>> and specifically symbolicate the code of the user programs. >>> >>> For example I often use the command showthreaduserstack defined here >>> http://opensource.apple.com//source/xnu/xnu-2422.1.72/tools/lldbmacros/userspace.py >>> to take >>> a look at the user stack of a process running in kernel mode that just >>> scripts the process of >>> obtaining the thread saved state, but the output unfortunately isn't >>> symbolicated. >>> >>> Is there a way to add symbols for a user process (programs and shared libs?) >>> I looked into the target modules add command, but when I try to add a >>> copy of the executable >>> it just says that the file I pick doesn't exist (even though it clearly >>> exist). >>> Also I'm not entirely sure how that would work since the user space >>> addressing space changes >>> for every process, even if I manually set the loading address. >>> Would that work only for that specific process and execution? >>> >>> Regards, >>> John >>> ___ >>> 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] Variable shadowing
You can currently do this by checking for other variables to see if any names
match.
In python when stopped in the function below you can do use the API:
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> frame_vars = lldb.frame.GetVariables(True, True, True, True)
>>> print frame_vars
(int) v = 1
(int) v = 2
frame_vars is a list of all variables in the current stack frame. They are
ordered correctly so you see your first "v" first and the second one next.
Lets grab the exact lexical block from the current frame:
>>> block = lldb.frame.GetBlock()
This is the block from line 4 - 7 in your source code.
>>> print block.GetVariables(lldb.frame, True, True, True, 0)
(int) v = 2
Note that if we ask the block for its variables, it will only have the
variables contained in that block. Now you can ask "block" for its parent block:
>>> print block.GetParent().GetVariables(lldb.frame, True, True, True, 0)
(int) v = 1
So with all of this you could create a new python command:
#!/usr/bin/python
import lldb
import shlex
@lldb.command("check-shadow")
def check_shadow_command(debugger, command, result, dict):
target = debugger.GetSelectedTarget()
if not target:
print >>result, "invalid target"
return
process = target.GetProcess()
if not process:
print >>result, "invalid process"
return
thread = process.GetSelectedThread()
if not thread:
print >>result, "invalid thread"
return
frame = thread.GetSelectedFrame()
if not frame:
print >>result, "invalid frame"
return
# Parse command line args
command_args = shlex.split(command)
# TODO: add support for using arguments that are passed to this command...
# Make a dictionary of variable name to "SBBlock and SBValue"
var_dict = {}
# Get the deepest most block from the current frame
block = frame.GetBlock()
# Iterate through the block and all of its parents
while block.IsValid():
# Get block variables from the current block only
block_vars = block.GetVariables(frame, True, True, True, 0)
# Iterate through all variables in the current block
for block_var in block_vars:
# Get the variable name and see if we already have a variable by
this name?
block_var_name = block_var.GetName()
if block_var_name in var_dict:
# We already have seen a variable with this name, so it is
shadowed
print block, block_var
print 'is shadowed by:'
shadow_block_and_vars = var_dict[block_var_name]
for shadow_block_and_var in shadow_block_and_vars:
print shadow_block_and_var[0], shadow_block_and_var[1]
# Since we can have multiple shadowed variables, we our variable
# name dictionary to have an array or "block + variable" pairs so
# We can correctly print out all shadowed variables and whow which
# blocks they come from
if block_var_name in var_dict:
var_dict[block_var_name].append([block, block_var])
else:
var_dict[block_var_name] = [[block, block_var]]
# Get the parent block and continue
block = block.GetParent()
I have attached this as a script that you can import:
#!/usr/bin/python
import lldb
import shlex
@lldb.command("check-shadow")
def check_shadow_command(debugger, command, result, dict):
target = debugger.GetSelectedTarget()
if not target:
print >>result, "invalid target"
return
process = target.GetProcess()
if not process:
print >>result, "invalid process"
return
thread = process.GetSelectedThread()
if not thread:
print >>result, "invalid thread"
return
frame = thread.GetSelectedFrame()
if not frame:
print >>result, "invalid frame"
return
# Parse command line args
command_args = shlex.split(command)
# TODO: add support for using arguments that are passed to this command...
# Make a dictionary of variable name to "SBBlock and SBValue"
var_dict = {}
# Get the deepest most block from the current frame
block = frame.GetBlock()
# Iterate through the block and all of its parents
while block.IsValid():
# Get block variables from the current block only
block_vars = block.GetVariables(frame, True, True, True, 0)
# Iterate through all variables in the current block
for block_var in block_vars:
# Get the variable name and see if we already have a variable by this name?
block_var_name = block_var.GetName()
if block_var_name in var_dict:
# We already have seen a variable with this name, so it is shadowed
print block, block_var
print 'is shadowed by:'
Re: [lldb-dev] Variable shadowing
The logic is a bit wrong in my script, it should first print out the variables
we have already found, followed by the one we are currently processing. The
fixed script is attached:
#!/usr/bin/python
import lldb
import shlex
@lldb.command("check-shadow")
def check_shadow_command(debugger, command, result, dict):
target = debugger.GetSelectedTarget()
if not target:
print >>result, "invalid target"
return
process = target.GetProcess()
if not process:
print >>result, "invalid process"
return
thread = process.GetSelectedThread()
if not thread:
print >>result, "invalid thread"
return
frame = thread.GetSelectedFrame()
if not frame:
print >>result, "invalid frame"
return
# Parse command line args
command_args = shlex.split(command)
# TODO: add support for using arguments that are passed to this command...
# Make a dictionary of variable name to "SBBlock and SBValue"
var_dict = {}
# Get the deepest most block from the current frame
block = frame.GetBlock()
# Iterate through the block and all of its parents
while block.IsValid():
# Get block variables from the current block only
block_vars = block.GetVariables(frame, True, True, True, 0)
# Iterate through all variables in the current block
for block_var in block_vars:
# Get the variable name and see if we already have a variable by this name?
block_var_name = block_var.GetName()
if block_var_name in var_dict:
# We already have seen a variable with this name, so it is shadowed
shadow_block_and_vars = var_dict[block_var_name]
for shadow_block_and_var in shadow_block_and_vars:
print shadow_block_and_var[0], shadow_block_and_var[1]
print 'is shadowed by:'
print block, block_var
# Since we can have multiple shadowed variables, we our variable
# name dictionary to have an array or "block + variable" pairs so
# We can correctly print out all shadowed variables and whow which
# blocks they come from
if block_var_name in var_dict:
var_dict[block_var_name].append([block, block_var])
else:
var_dict[block_var_name] = [[block, block_var]]
# Get the parent block and continue
block = block.GetParent()
And the output is now correct:
(lldb) check-shadow
Block: {id: 94} [0x10f7b-0x10f8b) (int) v = 2
is shadowed by:
Block: {id: 46} [0x10f70-0x10f8d) (int) v = 1
> On Jun 22, 2016, at 1:57 PM, Greg Clayton via lldb-dev
> wrote:
>
> You can currently do this by checking for other variables to see if any names
> match.
>
> In python when stopped in the function below you can do use the API:
>
>
> (lldb) script
> Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
frame_vars = lldb.frame.GetVariables(True, True, True, True)
print frame_vars
> (int) v = 1
> (int) v = 2
>
> frame_vars is a list of all variables in the current stack frame. They are
> ordered correctly so you see your first "v" first and the second one next.
>
> Lets grab the exact lexical block from the current frame:
>
block = lldb.frame.GetBlock()
>
> This is the block from line 4 - 7 in your source code.
>
print block.GetVariables(lldb.frame, True, True, True, 0)
> (int) v = 2
>
> Note that if we ask the block for its variables, it will only have the
> variables contained in that block. Now you can ask "block" for its parent
> block:
>
print block.GetParent().GetVariables(lldb.frame, True, True, True, 0)
> (int) v = 1
>
>
> So with all of this you could create a new python command:
>
>
> #!/usr/bin/python
>
> import lldb
> import shlex
>
> @lldb.command("check-shadow")
> def check_shadow_command(debugger, command, result, dict):
>target = debugger.GetSelectedTarget()
>if not target:
>print >>result, "invalid target"
>return
>process = target.GetProcess()
>if not process:
>print >>result, "invalid process"
>return
>thread = process.GetSelectedThread()
>if not thread:
>print >>result, "invalid thread"
>return
>frame = thread.GetSelectedFrame()
>if not frame:
>print >>result, "invalid frame"
>return
># Parse command line args
>command_args = shlex.split(command)
># TODO: add support for using arguments that are passed to this command...
>
># Make a dictionary of variable name to "SBBlock and SBValue"
>var_dict = {}
>
># Get the deepest most block from the current frame
>block = frame.GetBlock()
># Iterate through the block and all of its parents
>while block.IsValid():
># Get block variables from the current block only
>block_vars = block.GetVariables(fr
[lldb-dev] lldb 3.8 on OSX unable to debug process
Hi I'm building LLDB v3.8 on my osx mac using Unix Makefiles and when I go and test it with the built debugserver, I get the following errors when passing "run": error: process exited with status -1 (unable to attach) I verified that attaching to a process also doesn't work. Is there a known issue with building debugserver and lldb on a mac using Unix Makefiles? Thanks Pierson ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
