Re: [lldb-dev] Accessing DWARF information from C++

[Greg Clayton via lldb-dev]

> On Oct 30, 2015, at 3:35 AM, Stefan Kratochwil via lldb-dev 
>  wrote:
> 
> Hi Greg,
> 
> thanks for your reply.
> 
> I am developing a dynamic software updating tool for dynamically linked C 
> libraries (in short: I want to patch dynamic libraries in-memory).
> 
> My goal is to achieve that without any code instrumentation. The main problem 
> is the state transformation between the old and the new version - here I need 
> as much type (and location) information as possible.
> 
> I am currently unaware of what types of information I _really_ need, so for 
> now, getting as much information as possible is my way to go. I guess that 
> the most important types of information will be:
> - size of primitives
> - size of pointers
> - type hierarchies and
> - the in memory-structure of compound data types
> 
> At the moment I am concentrating on the Linux / UNIX domain, so DWARF is my 
> preferred format.

This is all available through the LLDB API, so I would suggest using LLDB and 
its debug info agnostic APIs. Let me know if you need to know how to find 
certain kinds of information from our API and I can help get you up and running.

Greg Clayton

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

Re: [lldb-dev] [BUG?] Confusion between translation units?

[Greg Clayton via lldb-dev]

> On Nov 3, 2015, at 12:07 PM, Ramkumar Ramachandra  wrote:
> 
> Greg Clayton wrote:
>> Not really. If you can send me a concrete example of something that isn't 
>> working, it might help.
> 
> Reporting progress.
> 
> 1. `im loo -t` only ever finds one "best match", and the plist seems
> to have no effect on it.

Use the --all option and it should print all matches.

> 2. The plist parsing code does get executed. I checked with the
> debugger. I also checked symlink versus non-symlinked paths in the
> plist, which I'd missed last time. dwarfdump does not seem to read it,
> and `im loo` says nothing different, so I have no idea if anything
> really got remapped.


> 
> 3. I managed to catch this "unstable" case: you try something, it
> prints a huge error, you try something else in a different frame with
> the same type, it prints fine, you come back to the original thing and
> there's a smaller error.


So one thing know in LLDB: don't use the expression parser if you don't have to 
when you run into problems. "frame variable" will show you what you want to see 
if you are just inspecting a variable or members of a variable:

(lldb) frame variable F
(lldb) frame variable F.Linkage
(lldb) frame variable a->b.c->e[12]

"frame variable" knows how to use ".", "->", "[]" for array access or using a 
pointer as an array. It also knows how to prefix the string with "*" or "&":

(lldb) frame variable &F
(lldb) frame variable *a->b.my_ptr

So you should really use frame variable for your viewing needs. It doesn't do 
any expressions, but it will allow you to view your variable. You should use 
the expression parser when you need to call a function, do match, flow control 
or anything that isn't viewing variables.


> 
>frame #0: 0x000101c3ce8c libmwcgir_vm_rt.dylib`(anonymous
> namespace)::CgJITMemManager::endFunctionBody(this=0x00010e8637b0,
> F=0x00010a62ccc0, FunctionStart="�?^\n\x01",
> FunctionEnd="...")
> + 28 at CgJITMemoryManager.cpp:437
>   434(void)FunctionStart;
>   435(void)FunctionEnd;
>   436
> -> 437assert(FunctionEnd > FunctionStart);
>   438assert(FunctionStart == (uint8_T *)(CurBlock+1) &&
>   439   "Mismatched function start/end!");
>   440
> (lldb) p F
> error: field 'BasicBlocks' declared with incompatible types in
> different translation units ('BasicBlockListType' (aka
> 'llvm::iplist
>> ') vs. 'BasicBlockListType' (aka 'llvm::iplist llvm::ilist_traits >'))
> error: field 'ArgumentList' declared with incompatible types in
> different translation units ('ArgumentListType' (aka
> 'llvm::iplist >')
> vs. 'ArgumentListType' (aka 'llvm::iplist llvm::ilist_traits >'))
> error: field 'BasicBlocks' declared with incompatible types in
> different translation units ('BasicBlockListType' (aka
> 'llvm::iplist
>> ') vs. 'BasicBlockListType' (aka 'llvm::iplist llvm::ilist_traits >'))
> error: field 'Context' declared with incompatible types in different
> translation units ('llvm::LLVMContext &' vs. 'llvm::LLVMContext &')
> error: field 'GlobalList' declared with incompatible types in
> different translation units ('GlobalListType' (aka
> 'llvm::iplist llvm::ilist_traits >') vs. 'GlobalListType' (aka
> 'llvm::iplist llvm::ilist_traits >'))
> error: field 'FunctionList' declared with incompatible types in
> different translation units ('FunctionListType' (aka
> 'llvm::iplist >')
> vs. 'FunctionListType' (aka 'llvm::iplist llvm::ilist_traits >'))
> error: field 'AliasList' declared with incompatible types in different
> translation units ('AliasListType' (aka
> 'llvm::iplist
>> ') vs. 'AliasListType' (aka 'llvm::iplist llvm::ilist_traits >'))
> error: field 'NamedMDList' declared with incompatible types in
> different translation units ('NamedMDListType' (aka
> 'llvm::ilist') vs. 'NamedMDListType' (aka
> 'llvm::ilist'))
> error: field 'GlobalScopeAsm' declared with incompatible types in
> different translation units ('stri

Re: [lldb-dev] [BUG?] Confusion between translation units?

[Greg Clayton via lldb-dev]

> On Nov 3, 2015, at 1:12 PM, Ramkumar Ramachandra  wrote:
> 
> Greg Clayton wrote:
>> Be sure to use "frame variable" more as it will never run into these type 
>> importation problems when you need to view a variable or members of a 
>> variable.
>> 
>> It would be interesting to see the output of "frame variable" from frame 0 
>> and frame 4 and see if they differ at all.
> 
> `fr va` seems to fix the immediate problem, thanks! I'll let you know
> if I run into issues with it.
> 
> We really should fix the expression parser, no?

Yes, but we need to identify the problem.

> Why is it behaving strangely?

There are many clang::ASTContext objects in LLDB. 1 per module, 1 per target 
and 1 for each expression. We import types from one AST to another. When 
running expressions we import one type for "foo" from liba.so into the 
expression AST, then we might try to import another from libb.so into the 
expression AST. If the "foo" type is already in the expression AST, then 
we need to verify the two types are the same. When this fails, then the 
expression fails.

So we need to determine which two versions of "foo" are different and 
where they differ so we can understand how to fix this.

Follow my previous suggestions: enable lldb expr logging and also compare the 
output of the two "frame variable F" for frame 0 and frame 4 in your previous 
example. Since "frame variable" always uses the type _only_ from liba.so or 
libb.so, we might be able to see a difference in the output of "frame variable 
F" for the two frames. If we don't see any difference, we need to dump the type 
from "image lookup --all -t "foo" and see if we see any differences there. 
If we don't see differences we need to then step through the code that is 
attempting to import "foo" the second time and see where it thinks the 
types differ.

Greg Clayton

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

Re: [lldb-dev] Attaching to a stopped (cored) process hangs lldb-server

[Greg Clayton via lldb-dev]

One different approach is to have your tool write all STDIN to a file (the core 
file comes into the tool as STDIN bytes) and then hand LLDB the core file and 
do any needed backtracing and data gathering from the core file instead of 
actually attaching to the process for real. All executable and shared library 
object files (ELF files) from the core file are still on disk so you can get 
symbols and use the debug info, so LLDB should be able to load all frames up 
and symbolicate up the crash location. It should be just as good as having the 
process around without any bad side affects. Core files are less useful if they 
must be archived and symbolicated later because the executable files might not 
be around anymore since things like test suites might produce binaries for 
testing and remove them after the test is run or crashed.

What do you think about this approach?

Greg Clayton


> On Nov 2, 2015, at 5:54 PM, Mark Chandler via lldb-dev 
>  wrote:
> 
> So im trying to write a core handler program and use lldb to attach and dump 
> important information about it. This works if a use my tool to attach to an 
> existing one but I found that lldb-server will hang in a waitpid call if the 
> kernel has invoked the tool after another process has cored.
>  
> Example:
> · /proc/sys/kernel/core_pattern is set to |/opt/core_tool
> · Run a.out and it segfaults
> · Kernel invokes core_tool that uses lldb AttachToProcess and a.out 
> is in state “S+”
> · lldb-server hangs in 
> source\Plugins\Process\Linux\NativeProcessLinux.cpp:867
> · if I remove the waitpid it doesn’t hang but fails to attach
>  
> Looks like gdb had a similar problem as well: 
> http://www.sourceware.org/ml/gdb-patches/2008-04/msg00224.html
> Any ideas on how to fix this?
>  
> Mark Chandler
> Battle.Net Engineering Systems | Blizzard Entertainment
> (P) 949-955-1380 x15353
>  
> ___
> 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] Attaching to a stopped (cored) process hangs lldb-server

[Greg Clayton via lldb-dev]

So you would save the file, create a target:

const char *core_path = ...; // Save STDIN to a  file and put path in 
"core_path"
const bool source_init_files = false;
debugger = lldb::SBDebugger::Create(source_init_files);
target = debugger.CreateTarget(None);
process = target.LoadCore(core_path);
if (process.IsValid())
{
// Do any symbolication you need to on your process core file
// as it will behave just like a real process, you just can't run it
}


> On Nov 3, 2015, at 4:34 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> One different approach is to have your tool write all STDIN to a file (the 
> core file comes into the tool as STDIN bytes) and then hand LLDB the core 
> file and do any needed backtracing and data gathering from the core file 
> instead of actually attaching to the process for real. All executable and 
> shared library object files (ELF files) from the core file are still on disk 
> so you can get symbols and use the debug info, so LLDB should be able to load 
> all frames up and symbolicate up the crash location. It should be just as 
> good as having the process around without any bad side affects. Core files 
> are less useful if they must be archived and symbolicated later because the 
> executable files might not be around anymore since things like test suites 
> might produce binaries for testing and remove them after the test is run or 
> crashed.
> 
> What do you think about this approach?
> 
> Greg Clayton
> 
> 
>> On Nov 2, 2015, at 5:54 PM, Mark Chandler via lldb-dev 
>>  wrote:
>> 
>> So im trying to write a core handler program and use lldb to attach and dump 
>> important information about it. This works if a use my tool to attach to an 
>> existing one but I found that lldb-server will hang in a waitpid call if the 
>> kernel has invoked the tool after another process has cored.
>> 
>> Example:
>> · /proc/sys/kernel/core_pattern is set to |/opt/core_tool
>> · Run a.out and it segfaults
>> · Kernel invokes core_tool that uses lldb AttachToProcess and a.out 
>> is in state “S+”
>> · lldb-server hangs in 
>> source\Plugins\Process\Linux\NativeProcessLinux.cpp:867
>> · if I remove the waitpid it doesn’t hang but fails to attach
>> 
>> Looks like gdb had a similar problem as well: 
>> http://www.sourceware.org/ml/gdb-patches/2008-04/msg00224.html
>> Any ideas on how to fix this?
>> 
>> Mark Chandler
>> Battle.Net Engineering Systems | Blizzard Entertainment
>> (P) 949-955-1380 x15353
>> 
>> ___
>> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Attaching to a stopped (cored) process hangs lldb-server

[Greg Clayton via lldb-dev]

Makes sense about not writing the core file to disk. 

Is there a way you can detect this "core" mode where we don't have to waitpid? 
Seems like that www.sourceware.org message had ideas on how to detect this case?

Greg

> On Nov 3, 2015, at 4:36 PM, Mark Chandler  wrote:
> 
> Not able to do that as the servers have no hard drives (use ram disk and net 
> boot) and the tool is trying to avoid a core storm that takes down the 
> network file share. I found out what is causing it to hang, there is a call 
> to waitpid in NativeLinuxProcess.cpp that waits forever. As the process is 
> already stopped, I disabled that and it looks to be working
> 
> Mark Chandler
> Battle.Net Engineering Systems | Blizzard Entertainment
> (P) 949-955-1380 x15353
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com] 
> Sent: Tuesday, November 03, 2015 4:34 PM
> To: Mark Chandler 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Attaching to a stopped (cored) process hangs 
> lldb-server
> 
> One different approach is to have your tool write all STDIN to a file (the 
> core file comes into the tool as STDIN bytes) and then hand LLDB the core 
> file and do any needed backtracing and data gathering from the core file 
> instead of actually attaching to the process for real. All executable and 
> shared library object files (ELF files) from the core file are still on disk 
> so you can get symbols and use the debug info, so LLDB should be able to load 
> all frames up and symbolicate up the crash location. It should be just as 
> good as having the process around without any bad side affects. Core files 
> are less useful if they must be archived and symbolicated later because the 
> executable files might not be around anymore since things like test suites 
> might produce binaries for testing and remove them after the test is run or 
> crashed.
> 
> What do you think about this approach?
> 
> Greg Clayton
> 
> 
>> On Nov 2, 2015, at 5:54 PM, Mark Chandler via lldb-dev 
>>  wrote:
>> 
>> So im trying to write a core handler program and use lldb to attach and dump 
>> important information about it. This works if a use my tool to attach to an 
>> existing one but I found that lldb-server will hang in a waitpid call if the 
>> kernel has invoked the tool after another process has cored.
>> 
>> Example:
>> · /proc/sys/kernel/core_pattern is set to |/opt/core_tool
>> · Run a.out and it segfaults
>> · Kernel invokes core_tool that uses lldb AttachToProcess and a.out 
>> is in state “S+”
>> · lldb-server hangs in 
>> source\Plugins\Process\Linux\NativeProcessLinux.cpp:867
>> · if I remove the waitpid it doesn’t hang but fails to attach
>> 
>> Looks like gdb had a similar problem as well: 
>> http://www.sourceware.org/ml/gdb-patches/2008-04/msg00224.html
>> Any ideas on how to fix this?
>> 
>> Mark Chandler
>> Battle.Net Engineering Systems | Blizzard Entertainment
>> (P) 949-955-1380 x15353
>> 
>> ___
>> 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] Attaching to a stopped (cored) process hangs lldb-server

[Greg Clayton via lldb-dev]

Can someone with linux experience chime in here? It shouldn't be too hard to 
figure out which flag 'S' is in. On MacOS we can get a process info structure 
from a pid and that will have bits set that indicate 'S'...

If you want to checkin this tool into the LLDB source tree at 
trunk/tools/core_tool then we can get more people to work on it and improve it. 
It would be nice to have this available for all linux users. I would love to 
see an JSON output mode that is parseable by automated tools instead of people 
saving text formats that must be text scraped.

If you can get this into a tool, others can help get this working. Any interest 
in this?

Greg

> On Nov 3, 2015, at 4:41 PM, Mark Chandler  wrote:
> 
> The biggest tell is that the process state is already 'S' or stopped. I don’t 
> know lldb at all to make a change to fix this though.
> 
> 
> Mark Chandler
> Battle.Net Engineering Systems | Blizzard Entertainment
> (P) 949-955-1380 x15353
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com] 
> Sent: Tuesday, November 03, 2015 4:39 PM
> To: Mark Chandler 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Attaching to a stopped (cored) process hangs 
> lldb-server
> 
> Makes sense about not writing the core file to disk. 
> 
> Is there a way you can detect this "core" mode where we don't have to 
> waitpid? Seems like that www.sourceware.org message had ideas on how to 
> detect this case?
> 
> Greg
> 
>> On Nov 3, 2015, at 4:36 PM, Mark Chandler  wrote:
>> 
>> Not able to do that as the servers have no hard drives (use ram disk and net 
>> boot) and the tool is trying to avoid a core storm that takes down the 
>> network file share. I found out what is causing it to hang, there is a call 
>> to waitpid in NativeLinuxProcess.cpp that waits forever. As the process is 
>> already stopped, I disabled that and it looks to be working
>> 
>> Mark Chandler
>> Battle.Net Engineering Systems | Blizzard Entertainment
>> (P) 949-955-1380 x15353
>> 
>> -Original Message-
>> From: Greg Clayton [mailto:gclay...@apple.com] 
>> Sent: Tuesday, November 03, 2015 4:34 PM
>> To: Mark Chandler 
>> Cc: lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] Attaching to a stopped (cored) process hangs 
>> lldb-server
>> 
>> One different approach is to have your tool write all STDIN to a file (the 
>> core file comes into the tool as STDIN bytes) and then hand LLDB the core 
>> file and do any needed backtracing and data gathering from the core file 
>> instead of actually attaching to the process for real. All executable and 
>> shared library object files (ELF files) from the core file are still on disk 
>> so you can get symbols and use the debug info, so LLDB should be able to 
>> load all frames up and symbolicate up the crash location. It should be just 
>> as good as having the process around without any bad side affects. Core 
>> files are less useful if they must be archived and symbolicated later 
>> because the executable files might not be around anymore since things like 
>> test suites might produce binaries for testing and remove them after the 
>> test is run or crashed.
>> 
>> What do you think about this approach?
>> 
>> Greg Clayton
>> 
>> 
>>> On Nov 2, 2015, at 5:54 PM, Mark Chandler via lldb-dev 
>>>  wrote:
>>> 
>>> So im trying to write a core handler program and use lldb to attach and 
>>> dump important information about it. This works if a use my tool to attach 
>>> to an existing one but I found that lldb-server will hang in a waitpid call 
>>> if the kernel has invoked the tool after another process has cored.
>>> 
>>> Example:
>>> · /proc/sys/kernel/core_pattern is set to |/opt/core_tool
>>> · Run a.out and it segfaults
>>> · Kernel invokes core_tool that uses lldb AttachToProcess and a.out 
>>> is in state “S+”
>>> · lldb-server hangs in 
>>> source\Plugins\Process\Linux\NativeProcessLinux.cpp:867
>>> · if I remove the waitpid it doesn’t hang but fails to attach
>>> 
>>> Looks like gdb had a similar problem as well: 
>>> http://www.sourceware.org/ml/gdb-patches/2008-04/msg00224.html
>>> Any ideas on how to fix this?
>>> 
>>> Mark Chandler
>>> Battle.Net Engineering Systems | Blizzard Entertainment
>>> (P) 949-955-1380 x15353
>>> 
>>> ___
>>> 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] Attaching to a stopped (cored) process hangs lldb-server

[Greg Clayton via lldb-dev]

> On Nov 4, 2015, at 9:47 AM, Todd Fiala  wrote:
> 
> Although doing any kind of waitpid() in the case of a core file doesn't make 
> sense.

The process is still around. The process is being handed the core file via 
STDIN, but the process is still around and this tool is attaching to that 
process and ignoring the core file data. I would vote to use the core file data 
if the tool is checked in, or at least provide an option to either attach to 
the process or use the core file data...

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

Re: [lldb-dev] Attaching to a stopped (cored) process hangs lldb-server

[Greg Clayton via lldb-dev]

So the entire core file is in memory somehow and when it is read from STDIN 
will be then be freed? Seems like a really lame way to pass the core file 
around as it requires up to 2x the size of the core in memory. We could add a 
new version of SBTarget::LoadCore() like:

SBProcess
SBTarget::LoadCoreFromData(const void *data, uint64_t data_len);

But this will be a memory hog depending on if the memory from STDIN containing 
the core file gets freed immediately after it is consumed, or if the data is 
still around.


> On Nov 4, 2015, at 10:05 AM, Mark Chandler  wrote:
> 
> The problem becomes when the core data on stdin is gigabytes in size and 
> there is little to no diskspace or memory (as the process is still around) to 
> store/process the data.
> 
> 
> Mark Chandler
> Battle.Net Engineering Systems | Blizzard Entertainment
> (P) 949-955-1380 x15353
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com] 
> Sent: Wednesday, November 04, 2015 10:01 AM
> To: Todd Fiala 
> Cc: Mark Chandler ; Pavel Labath ; 
> lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Attaching to a stopped (cored) process hangs 
> lldb-server
> 
> 
>> On Nov 4, 2015, at 9:47 AM, Todd Fiala  wrote:
>> 
>> Although doing any kind of waitpid() in the case of a core file doesn't make 
>> sense.
> 
> The process is still around. The process is being handed the core file via 
> STDIN, but the process is still around and this tool is attaching to that 
> process and ignoring the core file data. I would vote to use the core file 
> data if the tool is checked in, or at least provide an option to either 
> attach to the process or use the core file data...
> 
> Greg

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

Re: [lldb-dev] [BUG?] Confusion between translation units?

[Greg Clayton via lldb-dev]

I will need to pass this to Sean Callanan to see if he can tell anything. It 
might be a few days before he can get to it.

I'll let you know when I know more.

> On Nov 4, 2015, at 12:10 PM, Ramkumar Ramachandra  wrote:
> 
> Greg Clayton  wrote:
>> Follow my previous suggestions: enable lldb expr logging and also compare 
>> the output of the two "frame variable F" for frame 0 and frame 4 in your 
>> previous example. Since "frame variable" always uses the type _only_ from 
>> liba.so or libb.so, we might be able to see a difference in the output of 
>> "frame variable F" for the two frames. If we don't see any difference, we 
>> need to dump the type from "image lookup --all -t "foo" and see if we 
>> see any differences there. If we don't see differences we need to then step 
>> through the code that is attempting to import "foo" the second time and 
>> see where it thinks the types differ.
> 
> Wow, it looks like lldb is doing an *enormous* amount of work to
> evaluate an expression. I've attached the logging on f 0 and f 4, as
> well as the image lookup output (doesn't seem to differ?).
> 
> I'll try to work my way through the dumps in the meantime. Let me know
> if anything immediately stands out.
> 

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

Re: [lldb-dev] Link warnings about lldb::endian::InlHostByteOrder()

[Greg Clayton via lldb-dev]

> On Nov 5, 2015, at 1:21 AM, Bruce Mitchener via lldb-dev 
>  wrote:
> 
> Greg et al:
> 
> When linking (cmake on OS X), I get a lot of warnings like this:
> 
>   ld: warning: cannot export hidden symbol lldb::endian::InlHostByteOrder()
>   from 
> lib/liblldbPluginProcessUtility.a(RegisterContextDarwin_arm64.cpp.o)
> 
> Should this function be in the public namespace?

No I don't believe it should. 

> It is an inline function which is why I think it gets flagged as hidden.
> 
> Can we move it out of the lldb namespace? Or has that ship sailed? Is there 
> some other way that we can suppress this warning or fix the underlying issue? 
> (Can we exclude a symbol from being exported somehow?)

Please feel free to move it to the lldb_private namespace. Nothing in our 
lldb/API/SB* header files should use it, so it is fine to move it. Let me know 
if you run into any troubles doing so.

> This isn't the only symbol that is a problem, but it is the one that 
> generates the most output.

We should have no inlined functions in our public API if we can avoid it. That 
is a sure way to have people crash if we ever change anything and they linked 
against the inline code from the header file.

Greg Clayton

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

Re: [lldb-dev] LLDB expressions confused by overloading

[Greg Clayton via lldb-dev]

> On Nov 5, 2015, at 9:43 AM, Aidan Dodds via lldb-dev 
>  wrote:
> 
> I believe I have tracked down an interesting bug which related to LLDBs 
> expression parser.
> 
> In my target program I have a math library, a shared object which makes use 
> of clangs __attribute__((overloadable)) extension for C99.  This causes the 
> the function names in the math library to be mangled.
> A problem arises however since some of the function names mirror those 
> exported by libm.so, and the function names in libm are not mangled.
> 
> My problem scenario:
> If I call an expression during a debugging session, the symbol table of 
> libm.so is consulted first and a match will be found.  Later on in the 
> expression setup, any dwarf information will be consulted for functions with 
> this name.  libm.so doesn't have any debugging info attached, however the 
> math library of my target may.  In this case the expression will now call 
> which ever function it could first find dwarf info for, regardless of the 
> name mangling.
> 
> The net result is that a function will be called in my targets math library 
> that may not match the given function signature.  In my case this causes the 
> expression to raise a SEGFAULT and fail.  I was seeing an expression to call 
> a vector4 function, in fact call the vector 2 version behinds the scenes.
> 
> One solution to this problem seems to be to have the expression evaluator try 
> and first look for any functions that may have a mangled name for the given 
> function signature, and if that fails fall back to simply checking for the 
> unmangled version, as is currently done.
> 
> Would this make sense?
> 
> It seems less then ideal to have a clash of mangled and unmangled names, but 
> I can imagine this situation may not be all that rare.

The correct fix for this is to have the DWARFASTParserClang, when it parses the 
function prototype, recognize that a C function (check the language of the 
compile unit) has a mangled name and enable the corresponding bit in the 
clang::FunctionType so that the expression parser knows to look for the mangled 
name when someone uses it. Then no changes to the expression parser should be 
required.

Greg Clayton

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

Re: [lldb-dev] How to disassemble a section (python api)?

[Greg Clayton via lldb-dev]

Currently you can't disassemble a section, nor would you probably want to since 
there are padding bytes in between functions.

The easiest way is to get all SBSymbol objects and ask each one for the 
instructions if they are code:

(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> module = lldb.target.module['a.out']
>>> num_symbols = module.GetNumSymbols()
>>> for i in range(num_symbols):
... symbol = module.GetSymbolAtIndex(i)
... if symbol.GetType() == lldb.eSymbolTypeCode:
... print symbol
... instructions = symbol.GetInstructions(lldb.target)
... for inst in instructions:
... print inst
... 
id = {0x0004}, range = [0x00010f00-0x00010f20), 
name="foo(float)", mangled="_Z3foof"
a.out[0x10f00]: pushq  %rbp
a.out[0x10f01]: movq   %rsp, %rbp
a.out[0x10f04]: movss  %xmm0, -0x4(%rbp)
a.out[0x10f09]: cvttss2si -0x4(%rbp), %eax
a.out[0x10f0e]: shll   $0x1, %eax
a.out[0x10f11]: popq   %rbp
a.out[0x10f12]: retq   
a.out[0x10f13]: nopw   %cs:(%rax,%rax)
id = {0x0008}, range = [0x00010f20-0x00010f40), 
name="foo(int)", mangled="_Z3fooi"
a.out[0x10f20]: pushq  %rbp
a.out[0x10f21]: movq   %rsp, %rbp
a.out[0x10f24]: movl   %edi, -0x4(%rbp)
a.out[0x10f27]: movl   -0x4(%rbp), %edi
a.out[0x10f2a]: shll   $0x2, %edi
a.out[0x10f2d]: movl   %edi, %eax
a.out[0x10f2f]: popq   %rbp
a.out[0x10f30]: retq   
a.out[0x10f31]: nopw   %cs:(%rax,%rax)
id = {0x000c}, range = [0x00010f40-0x00010f90), name="main"
a.out[0x10f40]: pushq  %rbp
a.out[0x10f41]: movq   %rsp, %rbp
a.out[0x10f44]: subq   $0x30, %rsp
a.out[0x10f48]: movss  0x40(%rip), %xmm0
a.out[0x10f50]: movl   $0x0, -0x4(%rbp)
a.out[0x10f57]: movl   %edi, -0x8(%rbp)
a.out[0x10f5a]: movq   %rsi, -0x10(%rbp)
a.out[0x10f5e]: movq   %rdx, -0x18(%rbp)
a.out[0x10f62]: movss  %xmm0, -0x1c(%rbp)
a.out[0x10f67]: movl   $0x4d2, -0x20(%rbp)
a.out[0x10f6e]: movss  -0x1c(%rbp), %xmm0
a.out[0x10f73]: callq  0x10f00
a.out[0x10f78]: movl   -0x20(%rbp), %edi
a.out[0x10f7b]: movl   %eax, -0x24(%rbp)
a.out[0x10f7e]: callq  0x10f20
a.out[0x10f83]: movl   -0x24(%rbp), %edi
a.out[0x10f86]: addl   %eax, %edi
a.out[0x10f88]: movl   %edi, %eax
a.out[0x10f8a]: addq   $0x30, %rsp
a.out[0x10f8e]: popq   %rbp
a.out[0x10f8f]: retq   
>>> 


If you want the symbols only from a specific section you can get the section 
from the symbol's start address and compare that to a given name:

section_name = ".text"
for i in range(num_symbols):
symbol = module.GetSymbolAtIndex(i)
if symbol.GetType() == lldb.eSymbolTypeCode:
symbol_section = symbol.GetStartAddress().GetSection()
if symbol_section.GetName() == section_name:
print symbol
instructions = symbol.GetInstructions(lldb.target)
for inst in instructions:
print inst





> On Nov 12, 2015, at 2:13 PM, kwadwo amankwa via lldb-dev 
>  wrote:
> 
> Hi
> I'm writing a small script and need to disassemble a whole section , what 
> would be the correct way to go about it ?
> 
> Cheers Que,
> ___
> 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] No machine instructions loaded for symbols or target (python api)

[Greg Clayton via lldb-dev]

It sounds like the symbols in the symbol table don't have valid sizes when they 
really should. What kind of executable are you debugging? A PECOFF file? If so, 
you should take a look at and fix the code in:

Symtab *
ObjectFilePECOFF::GetSymtab()

What we do for mach-o is to parse the symbol table first and then run back 
through all symbols, and any symbol that have a size of zero, set their sizes 
to the delta between the current symbol and the next addressed symbol. Since 
the symbols are usually out of order address wise, we run through all symbols 
that have addresses and add their indexes to a std::vector, then sort the 
vector of address indexes, and then we can do the above fixups.

Greg Clayton


> On Nov 17, 2015, at 4:21 AM, kwadwo amankwa via lldb-dev 
>  wrote:
> 
> Hi,
> I'm building an application on windows using the python api. I need to be 
> able to access a code symbols instructions but when I launch the process the 
> symbol has no instructions. I can manually read the symbols address space but 
> the symbol also has no end_addr set which makes it difficult to tell where 
> the symbol ends .
> Can anybody help me to find out how to generate the instructions when the 
> process is loaded ?
> 
> cheers,
> 
> Que
> ___
> 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] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback

[Greg Clayton via lldb-dev]

I fixed this:

% svn commit
Sendinginclude/lldb/Symbol/TypeMap.h
Sendingsource/Symbol/SymbolContext.cpp
Sendingsource/Symbol/TypeMap.cpp
Transmitting file data ...
Committed revision 253618.


> On Nov 18, 2015, at 12:54 AM, Ravitheja Addepally via lldb-dev 
>  wrote:
> 
> Hello,
>  Pavel- my question is how do we solve it ? should Mikhail log a bug ? 
> for this issue 
> 
> BR,
> A Ravi Theja
> 
> On Tue, Nov 17, 2015 at 10:42 AM, Ravitheja Addepally 
>  wrote:
> Hello,
> 
> Yeah you are right Mikhail, thanks for pointing it out, I 
> must ask, is there any bug already logged for this issue ?
> 
> Ravi
> 
> 
> On Mon, Nov 16, 2015 at 5:24 PM, Mikhail Filimonov via lldb-dev 
>  wrote:
> Hi guys and thank you for the excellent community project!
> 
>  
> 
> Recently I’ve stumbled on a pesky, but trivial Invalid iterator dereference 
> bug in SymbolContext and TypeMap implementations at revisions
> 
> https://github.com/llvm-mirror/lldb/blob/e528da256d14ecac7df858462b44dca931879509/source/Symbol/SymbolContext.cpp#L823
> 
> and
> 
> https://github.com/llvm-mirror/lldb/blob/5ac1fc5bc961688505334395598a2bb174eabd3b/source/Symbol/TypeMap.cpp#L172
> 
>  
> 
> From the code below it is obvious that TypeMap::ForEach calls the 
> pre-increment operator on m_types iterator right after it has been 
> invalidated by m_types.erase
> 
>  
> 
> SymbolContext::SortTypeList(TypeMap &type_map, TypeList &type_list ) const
> 
> {
> 
> TypeMaptoList callbackM2L (type_map, type_list);
> 
> type_map.ForEach(callbackM2L);
> 
> return ;
> 
> }
> 
>  
> 
> void
> 
> TypeMap::ForEach (std::function  const &callback)
> 
> {
> 
> for (auto pos = m_types.begin(), end = m_types.end(); pos != end; ++pos)
> 
> {
> 
> if (!callback(pos->second))
> 
> break;
> 
> }
> 
> }
> 
>  
> 
> bool
> 
> TypeMap::RemoveTypeWithUID (user_id_t uid)
> 
> {
> 
> iterator pos = m_types.find(uid);
> 
>
> 
> if (pos != m_types.end())
> 
> {
> 
> m_types.erase(pos);
> 
> return true;
> 
> }
> 
> return false;
> 
> }
> 
>  
> 
> class TypeMaptoList
> 
> {
> 
> public:
> 
> TypeMaptoList(TypeMap &typem, TypeList &typel) :
> 
> type_map(typem),type_list(typel)
> 
> {
> 
> }
> 
>  
> 
> bool
> 
> operator() (const lldb::TypeSP& type)
> 
> {
> 
> if(type)
> 
> {
> 
> type_list.Insert(type);
> 
> type_map.RemoveTypeWithUID(type->GetID());
> 
> if (type_map.Empty())
> 
> return false;
> 
> }
> 
> return true;
> 
> }
> 
>  
> 
> private:
> 
> TypeMap &type_map;
> 
> TypeList &type_list;
> 
> };
> 
>  
> 
> Regards,
> 
> Mikhail Filimonov
> 
>  
> 
>  
> 
>  
> 
> This email message is for the sole use of the intended recipient(s) and may 
> contain confidential information.  Any unauthorized review, use, disclosure 
> or distribution is prohibited.  If you are not the intended recipient, please 
> contact the sender by reply email and destroy all copies of the original 
> message.
> 
> ___
> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Auditing dotest's command line options

[Greg Clayton via lldb-dev]

Zach, I would also like to get rid of all global variables in the process of 
this change. The history goes like this: a long time ago someone wrote the 
initial dotest.py and parsed the options manually and stored results in global 
variables. Later, someone converted the options over to use a python library to 
parse the options, but we mostly copied the options from the options dictionary 
over into the globals and still use the globals all over the code. It would be 
great if we had at most one global variable that is something like "g_options" 
and anyone that was using any global variables will switch over to use the 
"g_options." instead. Then we don't have to make copies and we can let the 
g_options contain all settings that are required.

> On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> I would like to do a complete audit of dotest's command line options, find 
> out who's using what, and then potentially delete anything that isn't being 
> used.  There's a mess of command line options in use, to the point that it's 
> often hard to find free letters to use for new options.
> 
> I created this spreadsheet with a complete list of command line options, 
> their descriptions, and a place for people to enter what options they're 
> using or do not want to be deleted.
> 
> https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing
> 
> If someone has already written YES in the box that indicates they need the 
> option, please don't overwrite it.  If you write YES in a box, please provide 
> at least a small rationale for why this option is useful to you.  Feel free 
> to add additional rationale if someone has already added some rationale.
> 
> I'm going to have a couple days in mid-December and do this cleanup, so I'd 
> like to get a solid picture of what options are not needed before then.  
> After people have had some time to look over this, I'll go through the 
> results and decide what to do with each one, and then send out another email 
> with a proposed action column for each command line option.  
> 
> Please do take the time to have a look at this, because any option that 
> doesn't have a YES in it after a couple of weeks I'm going to assume is a 
> candidate for deletion.
> 
> 
> ___
> 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] lldb with app using shared lib not working

[Greg Clayton via lldb-dev]

You can else set environment variables when you launch manually:

(lldb) process launch -v DYLD_FRAMEWORK_PATH=/tmp -- arg1 arg2

"env" is nice because it sets it permanently for your target and you don't have 
to specify it over and over. But it you ever want to _sometimes_ launch with a 
different framework, the "-v" or "--environemnt" option to process launch can 
come in handy.

Greg 

> On Nov 20, 2015, at 5:06 AM, Andre Alefeld via lldb-dev 
>  wrote:
> 
> FYI,
> 
> I found the solution to the problem:
> DYLD_* env variables are purged from the environment due to SIP in El Capitan.
> It is necessary to set any DYLD_* variable settings within (lldb)
> 
> e.g.
> lldb -f DARWIN_X64/test_app
> (lldb) target create "DARWIN_X64/test_app"
> Current executable set to 'DARWIN_X64/test_app' (x86_64).
> (lldb) env DYLD_LIBRARY_PATH=
> (lldb) r
> 
> then the shared lib is honored as expected inside lldb.
> 
>  
> 
>  Forwarded Message 
> Subject:  lldb with app using shared lib not working
> Date: Thu, 19 Nov 2015 13:24:46 +0100
> From: Andre Alefeld 
> To:   lldb-dev@lists.llvm.org
> 
> Hi,
> 
> if I try to debug an application from the terminal that is using a
> shared lib lldb complains always about not finding the library even
> though everything is loading correctly when starting the app directly
> from the same terminal:
> 
> echo $DYLD_LIBRARY_PATH/
> 
> 
> running with debugger, shared lib can be loaded:
> test_app
> 
> otool -L DARWIN_X64/test_app
> DARWIN_X64/test_app:
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1225.1.1)
> libmyapp.dylib (compatibility version 0.0.0, current version 0.0.0)
> 
> 
> 
> lldb -f DARWIN_X64/test_app
> (lldb) target create "DARWIN_X64/test_app"
> Current executable set to 'DARWIN_X64/test_app' (x86_64).
> (lldb) r
> Process 32234 launched: '/Users/xxx/yyy/zzz/source/DARWIN_X64/test_app'
> (x86_64)
> dyld: Library not loaded: libmyapp.dylib
>   Referenced from: /Users/xxx/yyy/zzz/source/DARWIN_X64/test_app
>   Reason: image not found
> Process 32234 stopped
> * thread #1: tid = 0x85c524, 0x7fff5fc01075 dyld`dyld_fatal_error +
> 1, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
> frame #0: 0x7fff5fc01075 dyld`dyld_fatal_error + 1
> dyld`dyld_fatal_error:
> ->  0x7fff5fc01075 <+1>: nop   
> 
> dyld`dyldbootstrap::start:
> 0x7fff5fc01076 <+0>: pushq  %rbp
> 0x7fff5fc01077 <+1>: movq   %rsp, %rbp
> 0x7fff5fc0107a <+4>: pushq  %r15
> 
> 
> how can I achieve that the shared lib is used in the debugger correctly,
> do I have to set some additional environment variables. Is there a
> special r (process launch) syntax that I need to use ?
> 
> in gdb it used to work like a charm...
> 
> thanks for any help you can deliver in advance,
> 
> Andre
> 
> 
> 
> 
> 
> ___
> 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] Inquiry about .debug_frame

[Greg Clayton via lldb-dev]

Most compilers emit the same thing for EH frame and for .debug_frame. If this 
does indeed differ, then LLDB should parse both, but any such changes should 
really do so in a way that prefers .debug_frame over .eh_frame since 
.debug_frame should be complete unwind info even though it is just he same as 
the .eh_frame for most compilers.


> On Nov 24, 2015, at 5:50 AM, Ravitheja Addepally via lldb-dev 
>  wrote:
> 
> Hello,
>While compiling with clang for i386, I notice that the CFI information 
> is distributed between the .eh_frame section and the .debug_frame section, 
> meaning for some functions the CFI info is present in the .debug_frame 
> section whereas for some it is present in the .eh_frame. Now looking at the 
> lldb code,  I see that this information is only read from the .eh_frame 
> section and not from the .debug_frame section. My questions are the following 
> ->
> 1) Is there something that I missing ? is the  information that I provided in 
> this email correct ?
> 2) If it is correct, is this expected behavior ? I mean if the CFI info is 
> present in the .debug_frame then I think it should be read ? coz it maybe 
> useful in unwinding scenarios ?
> 
> 
> BR,
> A Ravi
> 
> ___
> 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] Linux core dump doesn't show listing when loaded

[Greg Clayton via lldb-dev]

"thread list" should just list the threads and their stop reasons (no 
backtraces). If you want backtraces just do "thread backtrace all".


On Nov 24, 2015, at 1:09 PM, Ted Woodward via lldb-dev 
 wrote:
> 
> I’ve been working on an old rev that we’d released on; now I’m much closer to 
> ToT as we move towards our next major Hexagon release.
>  
> Core dumps on the old rev would print out a listing/disassembly for each 
> thread in the core dump. Now it doesn’t.
>  
> ToT does this, on x86 Linux:
>  
> >bin/lldb ~/lldb_test/coredump/lincrash -c ~/lldb_test/coredump/lincore
> (lldb) target create "/usr2/tedwood/lldb_test/coredump/lincrash" --core 
> "/usr2/tedwood/lldb_test/coredump/lincore"
> Core file '/usr2/tedwood/lldb_test/coredump/lincore' (x86_64) was loaded.
> (lldb) thread list
> Process 0 stopped
> * thread #1: tid = 0, 0x00401190 lincrash`main + 16 at lincrash.c:5, 
> name = 'lincrash', stop reason = signal SIGSEGV
> (lldb)
>  
> I can see the listing by going up and down the stack, but I’d like to see the 
> listing on load. Is the no listing intended?
>  
> Ted
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> ___
> 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] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

So be sure to enable -fno-limit-debug-info to make sure the compiler isn't 
emitting lame debug info. 

If things are still failing, check to see what we think "CG::Node" contains by 
dumping the type info for it:

(lldb) image lookup -t CG::Node

This will print out the complete class definition that we have for "CG::Node" 
including ivars and methods. You should be able to see the inheritance 
structure and you might need to also dump the type info for each inherited 
class.

Compilers have been trying to not output a bunch of debug info and in the 
process they started to omit class info for base classes. So if you have:

class A : public B
{
};

where class "B" has all sorts of interesting methods, the debug info will often 
look like:

class B; // Forward declaration for class B

class A : public B
{
};

When this happens, we must make class A in a clang::ASTContext in 
DWARFASTParserClang and if "B" is a forward declaration, we can't leave it as a 
forward declaration or clang will assert and kill the debugger, so currently we 
just say "oh well, the compiler gave us lame debug info, and clang will crash 
if we don't fix this, so I am going to pretend we have a definition for class B 
and it contains nothing".

I really don't like that the compiler thinks this is OK to do, but that is the 
reality and we have to deal with it. 

So the best thing I can offer it you must use -fno-limit-debug-info when 
compiling to stop the compiler from doing this and things should be back to 
normal for you. If this isn't what is happening, let us know what the "image 
lookup -t" output looks like and we can see what we can do.

Greg Clayton
> On Nov 25, 2015, at 10:00 AM, Ramkumar Ramachandra via lldb-dev 
>  wrote:
> 
> Hi,
> 
> Basic things are failing.
> 
> (lldb) p lhs
> (CG::VarExpr *) $0 = 0x00010d445ca0
> (lldb) p lhs->rootStmt()
> (CG::ExprStmt *) $1 = 0x00010d446290
> (lldb) p cg_pp_see_it(lhs->rootStmt())
> (const char *) $2 = 0x00010d448020 "%A = $3;"
> (lldb) p cg_pp_see_it(def->rootStmt())
> error: no member named 'rootStmt' in 'CG::Node'
> error: 1 errors parsing expression
> (lldb) p cg_pp_see_it(def)
> error: no matching function for call to 'cg_pp_see_it'
> note: candidate function not viable: no known conversion from
> 'CG::Node *' to 'CG_Obj *' for 1st argument
> error: 1 errors parsing expression
> 
> It's total junk; why can't it see the inheritance VarExpr -> Node ->
> CG_Obj? The worst part is that rootStmt() is a function defined on
> Node!
> 
> Ram
> ___
> 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] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

So the main question is probably that you have a "CG::Node" and it inherits 
from one or more other classes and we probably either didn't find definitions 
for one or more of these classes. I would like to verify this to make sure we 
understand the problem. Can you do a:

(lldb) image dump -t "CG::Node"

And then see what classes it inherits from by looking at the textual version of 
the class that gets dumped. And repeat the "image dump -t " for each 
class that "CG::Node" inherits from and let me know if any of these classes are 
empty (no methods or ivars) when they shouldn't be empty? 

The theory behind the compiler debug info reduction that is enabled by default 
(-flimit-debug-info) is there should be an actual definition of the base 
classes somewhere and the debugger should be able to find it. We need to 
determine if this is the case for this binary. There could be an LLDB bug where 
there is debug info for the base class, but LLDB doesn't find it. The main 
issue the debugger has with the reduced debug info is we don't currently look 
across shared library boundaries when creating the type from the debug info. So 
if you have "CG::Node" in one shared library (liba.so) and it inherits from 
"Bar" that is in another shared library (libb.so) we will run into this problem 
as the compiler might emit a forward declaration for "Bar" in the debug info 
for liba.so. When we debug, we might have the debug info from libb.so or we 
might not, so even if we are able to fix LLDB to mark classes that it has 
completed just to keep clang from asserting, we might not be able to fix up the 
debug info to make it work when debugging later. This is why I prefer to have 
the information up front even though it might be duplicated elsewhere. There 
are many valid reasons for reducing the size of debug info: compile times and 
link timers are shorter, debug info size is smaller, and more.

Greg



> On Nov 30, 2015, at 9:41 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> So be sure to enable -fno-limit-debug-info to make sure the compiler isn't 
> emitting lame debug info. 
> 
> If things are still failing, check to see what we think "CG::Node" contains 
> by dumping the type info for it:
> 
> (lldb) image lookup -t CG::Node
> 
> This will print out the complete class definition that we have for "CG::Node" 
> including ivars and methods. You should be able to see the inheritance 
> structure and you might need to also dump the type info for each inherited 
> class.
> 
> Compilers have been trying to not output a bunch of debug info and in the 
> process they started to omit class info for base classes. So if you have:
> 
> class A : public B
> {
> };
> 
> where class "B" has all sorts of interesting methods, the debug info will 
> often look like:
> 
> class B; // Forward declaration for class B
> 
> class A : public B
> {
> };
> 
> When this happens, we must make class A in a clang::ASTContext in 
> DWARFASTParserClang and if "B" is a forward declaration, we can't leave it as 
> a forward declaration or clang will assert and kill the debugger, so 
> currently we just say "oh well, the compiler gave us lame debug info, and 
> clang will crash if we don't fix this, so I am going to pretend we have a 
> definition for class B and it contains nothing".
> 
> I really don't like that the compiler thinks this is OK to do, but that is 
> the reality and we have to deal with it. 
> 
> So the best thing I can offer it you must use -fno-limit-debug-info when 
> compiling to stop the compiler from doing this and things should be back to 
> normal for you. If this isn't what is happening, let us know what the "image 
> lookup -t" output looks like and we can see what we can do.
> 
> Greg Clayton
>> On Nov 25, 2015, at 10:00 AM, Ramkumar Ramachandra via lldb-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> Basic things are failing.
>> 
>> (lldb) p lhs
>> (CG::VarExpr *) $0 = 0x00010d445ca0
>> (lldb) p lhs->rootStmt()
>> (CG::ExprStmt *) $1 = 0x00010d446290
>> (lldb) p cg_pp_see_it(lhs->rootStmt())
>> (const char *) $2 = 0x00010d448020 "%A = $3;"
>> (lldb) p cg_pp_see_it(def->rootStmt())
>> error: no member named 'rootStmt' in 'CG::Node'
>> error: 1 errors parsing expression
>> (lldb) p cg_pp_see_it(def)
>> error: no matching function for call to 'cg_pp_see_it'
>> note: candidate function not viable: no known conversion from
>> 'CG::Node *' to 'CG_Obj *' for 1st argument
>> error: 1 

Re: [lldb-dev] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

> On Nov 30, 2015, at 1:57 PM, Eric Christopher  wrote:
> 
> 
> 
> On Mon, Nov 30, 2015 at 9:41 AM Greg Clayton via lldb-dev 
>  wrote:
> So be sure to enable -fno-limit-debug-info to make sure the compiler isn't 
> emitting lame debug info.
> 
> 
> Greg cannot be more wrong here. There are some limitations to be aware of 
> when using limit debug info, but if the debug info exists for the type in the 
> object and debug info then it's the fault of the debugger.  

This is true and what we are going to determine. My follow up emails has 
instructions to help us determine this.

> The limitations are pretty well defined, which is "if you ship the debug info 
> for all parts of the project you've just built then it should work just 
> fine". It isn't clear whether or not this is the case here, but the compiler 
> isn't "emitting lame debug info". (Also, it's not clear which compiler you're 
> using anyhow so Greg's advice is doubly bad).

I shouldn't have said "lame", sorry for that. We do need to determine the root 
cause of this, so hopefully we can find out what the main issue is, again, see 
my follow up email that preceded this email.

LLDB can start marking up classes that it completes just to keep clang from 
asserting (we do this for base classes that are forward declarations and for 
member variable that are structs/classes whose type is a forward declaration) 
in a way such that when we copy the type from one AST to another we can 
possibly find the real version of the type from the other shared library and 
use the real definition. This does mean if you have debug info for one shared 
library but not the other we will still have reduced debugging abilities. 

On MacOSX, we don't enable -flimit-debug-info by default so we tend not to run 
into this issue as we don't require people to have debug info for everything in 
order to debug as kernel debugging is very affected by this on darwin. All 
other platforms have it on by default.

> 
> -eric
> 
> 
>  
> If things are still failing, check to see what we think "CG::Node" contains 
> by dumping the type info for it:
> 
> (lldb) image lookup -t CG::Node
> 
> This will print out the complete class definition that we have for "CG::Node" 
> including ivars and methods. You should be able to see the inheritance 
> structure and you might need to also dump the type info for each inherited 
> class.
> 
> Compilers have been trying to not output a bunch of debug info and in the 
> process they started to omit class info for base classes. So if you have:
> 
> class A : public B
> {
> };
> 
> where class "B" has all sorts of interesting methods, the debug info will 
> often look like:
> 
> class B; // Forward declaration for class B
> 
> class A : public B
> {
> };
> 
> When this happens, we must make class A in a clang::ASTContext in 
> DWARFASTParserClang and if "B" is a forward declaration, we can't leave it as 
> a forward declaration or clang will assert and kill the debugger, so 
> currently we just say "oh well, the compiler gave us lame debug info, and 
> clang will crash if we don't fix this, so I am going to pretend we have a 
> definition for class B and it contains nothing".
> 
> I really don't like that the compiler thinks this is OK to do, but that is 
> the reality and we have to deal with it.
> 
> So the best thing I can offer it you must use -fno-limit-debug-info when 
> compiling to stop the compiler from doing this and things should be back to 
> normal for you. If this isn't what is happening, let us know what the "image 
> lookup -t" output looks like and we can see what we can do.
> 
> Greg Clayton
> > On Nov 25, 2015, at 10:00 AM, Ramkumar Ramachandra via lldb-dev 
> >  wrote:
> >
> > Hi,
> >
> > Basic things are failing.
> >
> > (lldb) p lhs
> > (CG::VarExpr *) $0 = 0x00010d445ca0
> > (lldb) p lhs->rootStmt()
> > (CG::ExprStmt *) $1 = 0x00010d446290
> > (lldb) p cg_pp_see_it(lhs->rootStmt())
> > (const char *) $2 = 0x00010d448020 "%A = $3;"
> > (lldb) p cg_pp_see_it(def->rootStmt())
> > error: no member named 'rootStmt' in 'CG::Node'
> > error: 1 errors parsing expression
> > (lldb) p cg_pp_see_it(def)
> > error: no matching function for call to 'cg_pp_see_it'
> > note: candidate function not viable: no known conversion from
> > 'CG::Node *' to 'CG_Obj *' for 1st argument
> > error: 1 errors parsing expression
> >
> > It's total junk; why can't it see th

Re: [lldb-dev] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

> 
> This will print out the complete class definition that we have for "CG::Node" 
> including ivars and methods. You should be able to see the inheritance 
> structure and you might need to also dump the type info for each inherited 
> class.
> 
> Compilers have been trying to not output a bunch of debug info and in the 
> process they started to omit class info for base classes. So if you have:
> 
> class A : public B
> {
> };
> 
> where class "B" has all sorts of interesting methods, the debug info will 
> often look like:
> 
> class B; // Forward declaration for class B
> 
> class A : public B
> {
> };
> 
> When this happens, we must make class A in a clang::ASTContext in 
> DWARFASTParserClang and if "B" is a forward declaration, we can't leave it as 
> a forward declaration or clang will assert and kill the debugger, so 
> currently we just say "oh well, the compiler gave us lame debug info, and 
> clang will crash if we don't fix this, so I am going to pretend we have a 
> definition for class B and it contains nothing".
> 
> Why not lookup the definition of B in the debug info at this point rather 
> than making a stub/empty definition? (& if there is none, then, yes, I 
> suppose an empty definition of B is as good as anything, maybe - it's going 
> to produce some weird results, maybe)

LLDB creates types using only the debug info from the currently shared library 
and we don't take a copy of a type from another shared library when creating 
the types for a given shared library. Why? LLDB has a global repository of 
modules (the class that represents an executable or shared library in LLDB). If 
Xcode, or any other IDE that can debug more that one thing at a time has two 
targets: "a.out" and "b.out", they share all of the shared library modules so 
that if debug info has already been parsed in the target for "a.out" for the 
shared library "liba.so" (or any other shared library), then the "b.out" target 
has the debug info already loaded for "liba.so" because "a.out" already loaded 
that module (LLDB runs in the same address space as our IDE). This means that 
all debug info in LLDB currently creates types using only the info in the 
current shared library. When we debug "a.out" again, we might have recompiled 
"liba.so", but not "libb.so" and when we debug again, we don't need to reload 
the debug info for "libb.so" if it hasn't changed, we just reload "liba.so" and 
its debug info. When we rerun a target (run a.out again), we don't need to 
spend any time reloading any shared libraries that haven't changed since they 
are still in our global shared library cache. So to keep this global library 
cache clean, we don't allow types from another shared library (libb.so) to be 
loaded into another (liba.so), otherwise we wouldn't be able to reap the 
benefits of our shared library cache as we would always need to reload debug 
info every time we run. 

LLDB does have the ability, when displaying types, to grab types from the best 
source (other shared libraries), we just don't transplant types in the LLDB 
shared library objects (lldb_private::Module) versions of the types. We do 
currently assume that all classes that aren't pointers or references (or other 
types that can legally have forward declarations of structs or classes) are 
complete in our current model. 

There are modifications we can do to LLDB to deal with the partial debug info 
and possible lack thereof when the debug info for other shared libraries are 
not present, but we haven't done this yet in LLDB.

>  
> I really don't like that the compiler thinks this is OK to do, but that is 
> the reality and we have to deal with it.
> 
> GCC's been doing it for a while longer than Clang & it represents a 
> substantial space savings in debug info size - it'd be hard to explain to 
> users why Clang's debug info is so much (20% or more) larger than GCC's when 
> GCC's contains all the information required and GDB gives a good user 
> experience with that information and LLDB does not.

LLDB currently recreates types in a clang::ASTContext and this imposes much 
stricter rules on how we represent types which is one of the weaknesses of the 
LLDB approach to type representation as the clang codebase often asserts when 
it is not happy with how things are represented. This does payoff IMHO in the 
complex expressions we can evaluate where we can use flow control, define and 
use C++ lambdas, and write more than one statement when writing expressions. 
But it is definitely a tradeoff. GDB has its own custom type representation 
which can be better for dealing with the different kinds and completeness of 
debug info, but I am comfortable with our approach.

So we need to figure out what the root problem is here before we can go further 
and talk about any additional solutions or fixes that may be required.

Greg

>  
> So the best thing I can offer it you must use -fno-limit-debug-info when 
> compiling to stop the compiler from doing this an

Re: [lldb-dev] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

> On Nov 30, 2015, at 2:54 PM, David Blaikie  wrote:
> 
> 
> 
> On Mon, Nov 30, 2015 at 2:42 PM, Greg Clayton  wrote:
> >
> > This will print out the complete class definition that we have for 
> > "CG::Node" including ivars and methods. You should be able to see the 
> > inheritance structure and you might need to also dump the type info for 
> > each inherited class.
> >
> > Compilers have been trying to not output a bunch of debug info and in the 
> > process they started to omit class info for base classes. So if you have:
> >
> > class A : public B
> > {
> > };
> >
> > where class "B" has all sorts of interesting methods, the debug info will 
> > often look like:
> >
> > class B; // Forward declaration for class B
> >
> > class A : public B
> > {
> > };
> >
> > When this happens, we must make class A in a clang::ASTContext in 
> > DWARFASTParserClang and if "B" is a forward declaration, we can't leave it 
> > as a forward declaration or clang will assert and kill the debugger, so 
> > currently we just say "oh well, the compiler gave us lame debug info, and 
> > clang will crash if we don't fix this, so I am going to pretend we have a 
> > definition for class B and it contains nothing".
> >
> > Why not lookup the definition of B in the debug info at this point rather 
> > than making a stub/empty definition? (& if there is none, then, yes, I 
> > suppose an empty definition of B is as good as anything, maybe - it's going 
> > to produce some weird results, maybe)
> 
> LLDB creates types using only the debug info from the currently shared 
> library and we don't take a copy of a type from another shared library when 
> creating the types for a given shared library. Why? LLDB has a global 
> repository of modules (the class that represents an executable or shared 
> library in LLDB). If Xcode, or any other IDE that can debug more that one 
> thing at a time has two targets: "a.out" and "b.out", they share all of the 
> shared library modules so that if debug info has already been parsed in the 
> target for "a.out" for the shared library "liba.so" (or any other shared 
> library), then the "b.out" target has the debug info already loaded for 
> "liba.so" because "a.out" already loaded that module (LLDB runs in the same 
> address space as our IDE). This means that all debug info in LLDB currently 
> creates types using only the info in the current shared library. When we 
> debug "a.out" again, we might have recompiled "liba.so", but not "libb.so" 
> and when we debug again, we don't need to reload the debug info for "libb.so" 
> if it hasn't changed, we just reload "liba.so" and its debug info. When we 
> rerun a target (run a.out again), we don't need to spend any time reloading 
> any shared libraries that haven't changed since they are still in our global 
> shared library cache. So to keep this global library cache clean, we don't 
> allow types from another shared library (libb.so) to be loaded into another 
> (liba.so), otherwise we wouldn't be able to reap the benefits of our shared 
> library cache as we would always need to reload debug info every time we run.
> 
> Ah, right - I do remember you describing this to me before. Sorry I forgot.
> 
> Wouldn't it be sufficient to just copy the definition when needed? If the 
> type changes in an incompatible way in a dependent library, the user is up a 
> creek already, aren't they? (eg: libb.so is rebuilt with a new, incompatible 
> version of some type that liba.so uses, but liba.so is not rebuilt) Perhaps 
> you wouldn't be responsible for rebuilding the liba.so cache until it's 
> actually recompiled. Maybe?
>  

The fix to LLDB I want to do is to complete the type when we need to for base 
classes, but mark it with metadata. When we run expressions we create a new 
clang::ASTContext for each expression, and copy types over into it. The 
ASTImporter can be taught to look for the metadata on the class that says "I 
completed this class because I had to", and when copying it, we would grab the 
right type from the current version of libb.so. This keeps everyone happy: 
modules get their types with some classes completed but marked, and the 
expressions get the best version available in their AST contexts where if a 
complete version of the type is available we find it and copy it in place of 
the completed but incomplete version from the module AST.


> LLDB does have the ability, when displaying types, to grab types from the 
> best source (other shared libraries), we just don't transplant types in the 
> LLDB shared library objects (lldb_private::Module) versions of the types. We 
> do currently assume that all classes that aren't pointers or references (or 
> other types that can legally have forward declarations of structs or classes) 
> are complete in our current model.
> 
> There are modifications we can do to LLDB to deal with the partial debug info 
> and possible lack thereof when the debug info for other shared libraries are 
> not pre

Re: [lldb-dev] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

> On Nov 30, 2015, at 6:04 PM, Ramkumar Ramachandra  wrote:
> 
> On Mon, Nov 30, 2015 at 5:42 PM, Greg Clayton  wrote:
>> When we debug "a.out" again, we might have recompiled "liba.so", but not 
>> "libb.so" and when we debug again, we don't need to reload the debug info 
>> for "libb.so" if it hasn't changed, we just reload "liba.so" and its debug 
>> info. When we rerun a target (run a.out again), we don't need to spend any 
>> time reloading any shared libraries that haven't changed since they are 
>> still in our global shared library cache. So to keep this global library 
>> cache clean, we don't allow types from another shared library (libb.so) to 
>> be loaded into another (liba.so), otherwise we wouldn't be able to reap the 
>> benefits of our shared library cache as we would always need to reload debug 
>> info every time we run.
> 
> Tangential: gdb starts up significantly faster than lldb. I wonder
> what lldb is doing wrong.

LLDB loads all shared libraries that it can when it first launches and GDB 
doesn't. In GDB you pay for this when you run your program. So if you want to 
compare things, do something like:

- get the current time as time1
- set an executable file in GDB and LLDB
- set a breakpoint
- run and hit the breakpoint
- get the current time as time2 and subtract from time1 and note time 
measurement.

Load GDB and LLDB up with a nice fat clang with debug info and the time to run 
to a breakpoint as a nice example. 

> 
> Oh, this is if I use the lldb that Apple supplied. If I compile my own
> lldb with llvm-release, clang-release, and lldb-release, it takes like
> 20x the time to start up: why is this?

Not sure one this. 

Are you saying you build on MacOSX using the Xcode project and build the 
"Release" build configuration and it runs slower than the LLDB that is shipped 
by Apple? This shouldn't happen. One reason that this might be the case is the 
binaries you build are not stripped and have a TON of C++ names that are not 
exported through the LLDB.framework, but are in the symbol table. You can run 
"strip -Sx" on your LLDB.framework and it should remove these extra symbols.


> And if I use llvm-debug,
> clang-debug, lldb-debug, the time it takes is completely unreasonable.

Simple: optimized code is much faster

> 
>> LLDB currently recreates types in a clang::ASTContext and this imposes much 
>> stricter rules on how we represent types which is one of the weaknesses of 
>> the LLDB approach to type representation as the clang codebase often asserts 
>> when it is not happy with how things are represented. This does payoff IMHO 
>> in the complex expressions we can evaluate where we can use flow control, 
>> define and use C++ lambdas, and write more than one statement when writing 
>> expressions. But it is definitely a tradeoff. GDB has its own custom type 
>> representation which can be better for dealing with the different kinds and 
>> completeness of debug info, but I am comfortable with our approach.
> 
> Yeah, about that. I question the utility of evaluating crazy
> expressions in lldb: I've not felt the need to do that even once, and
> I suspect a large userbase is with me on this. What's important is
> that lldb should _never_ fail to inspect a variable: isn't this the #1
> job of the debugger?

I agree with you on this. "frame variable" should never fail you as it doesn't 
use the expression parser. "frame variable" and its rock solid functionality is 
what IDEs use to display variables in variable views. So use "frame variable" 
and all will be good.

The expression parser is more complex and requires some special handling due to 
how we represent the ASTs as a single AST for all compile units within a module 
(executable/shared library). We use clang as the expression parser and this 
won't change so even if we tried to limit the expression parser to only do what 
the GDB expression parser does it won't help. So we need to tame the beast and 
we need to track down why things are not evaluating correctly when they do go 
wrong.

So please help us to track any issues down that we are having as one bug fix 
can often lead to fixing a whole variety of different issues.

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

Re: [lldb-dev] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

So one other issue with removing debug info from the current binary for base 
classes that are virtual: if the definition for the base class changes in 
libb.so, but liba.so was linked against an older version of class B from 
libb.so, like for example:

class A : public B
{
int m_a;
};

If A was linked against a B that looked like this:

class B
{
virtual ~B();
int m_b;
};

Then libb.so was rebuilt and B now looks like:

class B
{
virtual ~B();
virtual int foo();
int m_b;
int m_bb;
};

Then we when displaying an instance of "A" using in liba.so that was linked 
against the first version of B, we would actually show you the new version of 
"B" and everything would look like it was using the new definition for B, but 
liba.so is actually linked against the old instance and the code in class A 
would probably crash at some point due to the compilation mismatch, but the 
user would never really see actually what the original program was linked 
against and possibly be able to see the issue and realize they need to 
recompile liba.so against libb.so. If full debug info is emitted we would be 
able to show the original structure for B. Not an issue that people are always 
going to run into, but it is a reason that I like to have all the info complete 
in the current binary.

Greg

> On Nov 30, 2015, at 3:32 PM, David Blaikie  wrote:
> 
> 
> 
> On Mon, Nov 30, 2015 at 3:29 PM, Greg Clayton  wrote:
> 
> > On Nov 30, 2015, at 2:54 PM, David Blaikie  wrote:
> >
> >
> >
> > On Mon, Nov 30, 2015 at 2:42 PM, Greg Clayton  wrote:
> > >
> > > This will print out the complete class definition that we have for 
> > > "CG::Node" including ivars and methods. You should be able to see the 
> > > inheritance structure and you might need to also dump the type info for 
> > > each inherited class.
> > >
> > > Compilers have been trying to not output a bunch of debug info and in the 
> > > process they started to omit class info for base classes. So if you have:
> > >
> > > class A : public B
> > > {
> > > };
> > >
> > > where class "B" has all sorts of interesting methods, the debug info will 
> > > often look like:
> > >
> > > class B; // Forward declaration for class B
> > >
> > > class A : public B
> > > {
> > > };
> > >
> > > When this happens, we must make class A in a clang::ASTContext in 
> > > DWARFASTParserClang and if "B" is a forward declaration, we can't leave 
> > > it as a forward declaration or clang will assert and kill the debugger, 
> > > so currently we just say "oh well, the compiler gave us lame debug info, 
> > > and clang will crash if we don't fix this, so I am going to pretend we 
> > > have a definition for class B and it contains nothing".
> > >
> > > Why not lookup the definition of B in the debug info at this point rather 
> > > than making a stub/empty definition? (& if there is none, then, yes, I 
> > > suppose an empty definition of B is as good as anything, maybe - it's 
> > > going to produce some weird results, maybe)
> >
> > LLDB creates types using only the debug info from the currently shared 
> > library and we don't take a copy of a type from another shared library when 
> > creating the types for a given shared library. Why? LLDB has a global 
> > repository of modules (the class that represents an executable or shared 
> > library in LLDB). If Xcode, or any other IDE that can debug more that one 
> > thing at a time has two targets: "a.out" and "b.out", they share all of the 
> > shared library modules so that if debug info has already been parsed in the 
> > target for "a.out" for the shared library "liba.so" (or any other shared 
> > library), then the "b.out" target has the debug info already loaded for 
> > "liba.so" because "a.out" already loaded that module (LLDB runs in the same 
> > address space as our IDE). This means that all debug info in LLDB currently 
> > creates types using only the info in the current shared library. When we 
> > debug "a.out" again, we might have recompiled "liba.so", but not "libb.so" 
> > and when we debug again, we don't need to reload the debug info for 
> > "libb.so" if it hasn't changed, we just reload "liba.so" and its debug 
> > info. When we rerun a target (run a.out again), we don't need to spend any 
> > time reloading any shared libraries that haven't changed since they are 
> > still in our global shared library cache. So to keep this global library 
> > cache clean, we don't allow types from another shared library (libb.so) to 
> > be loaded into another (liba.so), otherwise we wouldn't be able to reap the 
> > benefits of our shared library cache as we would always need to reload 
> > debug info every time we run.
> >
> > Ah, right - I do remember you describing this to me before. Sorry I forgot.
> >
> > Wouldn't it be sufficient to just copy the definition when needed? If the 
> > type changes in an incompatible way in a dependent library, the user is up 
> > a creek already, aren't they? (eg: libb.so is rebu

Re: [lldb-dev] Custom expression evaluation target options

[Greg Clayton via lldb-dev]

Each expression has a language so we should be able to get the Language* for 
renderscript:


lldb_private::Language* language = lldb_private::Language::FindPlugin 
(m_expr.GetLanguage());

Then you can add a new virtual class on lldb_private::Language that can get any 
additional compiler flags needed for expressions and just make it work? The 
renderscript language would set the appropriate ABI flags needed?

Greg


> On Dec 3, 2015, at 8:44 AM, Luke Drummond via lldb-dev 
>  wrote:
> 
> Hello all
> 
> I've recently tracked down a problem in the expression evaluation engine for 
> lldb, and I'm hoping for some historical context, and possibly some direction 
> on the most appropriate fix.
> 
> ## Problem
> 
> I'd like to be able to set some target options for the JIT when calling `expr 
> myRenderscriptFunction(some_arg)`, so that the JIT compiler generates calling 
> code that matches a given calling convention.
> 
> Expression evaluation on x86 targets for our RenderScript LanguageRuntime 
> requires the JIT to call a RenderScript function with a slightly different 
> ABI than the default detected ABI for the module, (vectors are required to be 
> passed in SSE registers) and there doesn't appear to be a way to configure 
> the `Clang::Compiler` object used in `lldb_private::ClangExpressionParser` to 
> use non-default code-generation options.
> 
> Unfortunately, for now there's no way to get the target options we need in 
> `lldb_private::ClangExpressionParser`. It seems that the constructor for the 
> ClangExpressionParser class hard-codes the target options based on some 
> possibly broken assumptions on the target hardware and ABI available:
> 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp?view=markup#l178
> 
> This has been marked a `TODO` in the source, so I've been working on the 
> assumption that there is no currently implemented way to do this, and have 
> been trying to work out the best way to approach this.
> 
> However, as any new implementation may involve touching codepaths I'm not 
> particularly familiar with - or that other people are actively working on - 
> I'd appreciate if anyone on list can suggest whether:
> 
>   1. There's a better way to do what I need (I hope this is the case).
>   2. If not (1) whether the TODOs/FIXMEs in the current ClangExpressionParser 
> implementation are being worked on already.
> 
> I notice that some of the folks at Imagination gave a similar problem 
> statement on this list, back in April, and it was suggested they encode the 
> processor specific features in the ELF header `e_flags` word (header offset 
> 0x24).
> 
>http://lists.llvm.org/pipermail/lldb-dev/2015-April/007295.html
> 
> I have checked the LLVM source tree, and it seems that there are no i386 
> specific flags specified at the present time, so this path doesn't solve the 
> issue either.
> 
>http://llvm.org/docs/doxygen/html/Support_2ELF_8h_source.html
> 
> These flags seem to be little-used, and a quick search of my current Linux 
> system's lib32 shared objects directory turned up only four files with 
> non-zero e_flags in their header. I've not been able to track down what they 
> mean (grepping GNU binutils was fruitless).
> 
> Any suggestions are welcome.
> 
> All the Best
> 
> Luke
> 
> -- 
> Codeplay Software Ltd.
> Level C, Argyle House, 3 Lady Lawson St, Edinburgh, EH3 9DR
> https://www.codeplay.com
> ___
> 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] LLDB using Valgrind's embedded gdbserver

[Greg Clayton via lldb-dev]

The issue is LLDB wants to know information in the registers in the register 
context regarding how they map to "generic" registers. For x86_64 this means:

LLDB_REGNUM_GENERIC_PC  -> rip
LLDB_REGNUM_GENERIC_SP  -> rsp
LLDB_REGNUM_GENERIC_FP  -> rbp
LLDB_REGNUM_GENERIC_RA  -> 
LLDB_REGNUM_GENERIC_FLAGS   -> rflags
LLDB_REGNUM_GENERIC_ARG1-> rdi
LLDB_REGNUM_GENERIC_ARG2-> rsi
LLDB_REGNUM_GENERIC_ARG3-> rdx
LLDB_REGNUM_GENERIC_ARG4-> rcx
LLDB_REGNUM_GENERIC_ARG5-> r8
LLDB_REGNUM_GENERIC_ARG6-> r9

We also want to know what DWARF register number each register has, what 
compiler register number (for EH frame) each register is, and more.

There are two ways to do this:

1 - if you want to change the LLDB code
2 - if you want to make this work by only modifying valgrind's GDB server

If you go with option 1, it looks like the bug here is in:

static void
AugmentRegisterInfoViaABI (RegisterInfo ®_info, ConstString reg_name, ABISP 
abi_sp)

It grabs the register info from the ABI and fills it in, but it wasn't filling 
in the generic register number. I just fixed this with:

r254743 | gclayton | 2015-12-04 10:37:48 -0800 (Fri, 04 Dec 2015) | 1 line

Fill in the generic register kind if in AugmentRegisterInfoViaABI if it is 
available.

So if you update your sources, it might start working.

If you don't want the change LLDB, you can make the XML returned for the 
registers contain extra attributes to specify these things. If you check the 
code in ProcessGDBRemote.cpp around line 4327:

bool
ParseRegisters (XMLNode feature_node, GdbServerTargetInfo &target_info, 
GDBRemoteDynamicRegisterInfo &dyn_reg_info, ABISP abi_sp)

You can see the extra attributes a "reg" element node can contain. 

We extended the XML to include keys that LLDB can use. The assert that is 
causing the crash is the fact that we are asking a register context for the 
"generic" register that is "arg1". If you can modify the XML that is returned 
to mark up the registers so the generic name is attached to each register, it 
will help out LLDB. "debugserver" actually used this modified XML, so to see 
what it would look like with all of the new things we added you can copy what 
you need from the XML below. But lets look at the definition for "rip" alone:

  

Note we specify regnum (the lldb register number), offset (the byte offset for 
this register in the register context), altname, group_id (the register group 
this should appear in, see the "groups" at the end of the XML to see the 
register set names), gcc_regnum which is the compiler register number, 
dwarf_regnum, and the generic register name ("pc", "sp", "fp", "arg1", "arg2", 
etc).

So our full XML which specifies the compiler register numbers, DWARF register 
numbers and generic register names looks like:

l


  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


  
  
  





So if you get the generic register numbers fixed, you should probably not be 
crashing anymore.

Greg Clayton




> On Dec 3, 2015, at 4:24 PM, Daniel Trebbien via lldb-dev 
>  wrote:
> 
> Hello,
> 
> I am working on enhancing Valgrind's embedded gdbserver to allow LLDB to use 
> it (https://bugs.kde.org/show_bug.cgi?id=356174 ).  After adding support for 
> 'qC' packets to the embedded gdbserver, LLDB is able to continue the halted 
> program running under Valgrind; however, a short moment later LLDB crashes.
> 
> I am using OS X 10.11.1 (15B42) and lldb-340.4.110.1.
> 
> The location of the segmentation fault is 
> ABISysV_x86_64::GetArgumentValues(lldb_private::Thread&, 
> lldb_private::ValueList&) const + 147:
> 
> [  0] 0x00010432d7ad 
> LLDB`ABISysV_x86_64::GetArgumentValues(lldb_private::Thread&, 
> lldb_private::ValueList&) const + 147 at ABISysV_x86_64.cpp:485:32
>481addr_t current_stack_argument = sp + 8; // jump over return 
> address
>482
>483uint32_t argument_register_ids[6];
>484
> -> 485argument_register_ids[0] = reg_ctx->GetRegisterInfo 
> (eRegisterKindGeneric, LLDB_REGNUM_GENERIC_ARG1)->kinds[eRegisterKindLLDB];
> 
> 
> Someone at Apple Developer Relations (ADR) informed me that unlike gdb, lldb 
> does not have an initial target definition set, and relies on the gdbserver 
> to tell it which registers the gdbserver supports.  This can be done either 
> by responding to 'qRegisterInfo XX' packets or to 
> 'qXfer:features:read:target.xml'.
> 
> ADR also informed me about the 
> plugin.process.gdb-remote.target-definition-file LLDB setting and the example 
> target definitions at 
> http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/
> I can confirm that using either x86_64_linux_target_definition.py or 
> x86_64_target_definition.py fixes the segfault issue.
> 
> Valgrind's gdbserver does not support qRe

Re: [lldb-dev] lldb doesn't work on centos7

[Greg Clayton via lldb-dev]

Yes the debug info does get bigger. But this is better than having the compiler 
omit the "std::string" definition so that you can't view stuff from the STL.

Greg

> On Nov 24, 2015, at 7:22 PM, 陶征霖 via lldb-dev  wrote:
> 
> Also I found that the size of my program binary increases from 140M to 180M 
> after -fno-limit-debug-info is added. Seems a lot of debug info is added?
> 
> 2015-11-25 10:24 GMT+08:00 陶征霖 :
> Hi Pavel,
> 
> Thanks for your reply. Seems lldb not finding the variable in the first place.
> 
> * thread #1: tid = 154, 0x00400e5e a.out`main + 94 at t.cpp:5, name = 
> 'a.out', stop reason = breakpoint 1.1
> frame #0: 0x00400e5e a.out`main + 94 at t.cpp:5
>2   using namespace std;
>3   int main() {
>4  string s = "aa";
> -> 5  cout << s;
>6   }
> (lldb) frame variable --raw-output s
> (std::__1::string) s = {}
> 
> I added -fno-limit-debug-info in my test, and it works now. But why?
> 
> Thanks,
> Zhenglin
> 
> 
> 
> 2015-11-24 19:21 GMT+08:00 Pavel Labath :
> HI,
> 
> a couple of random shots in the dark:
> 
> - could you paste the output of "frame variable --raw-output s"? (This
> disables lldb's type formatters. The goal is to see if the problem is
> in the formatter, or in lldb not finding the variable in the first
> place).
> 
> - could you compile your test executable with -fno-limit-debug-info
> and see if that helps?
> 
> pl
> 
> 
> On 23 November 2015 at 02:15, 陶征霖 via lldb-dev  
> wrote:
> >
> > -- Forwarded message --
> > From: 陶征霖 
> > Date: 2015-11-20 23:10 GMT+08:00
> > Subject: lldb doesn't work on centos7
> > To: llvm-...@lists.llvm.org
> >
> >
> > Hi,
> >
> > I build llvm+clang+lldb 3.7.0 from source code on centos7, the build command
> > is "cmake -DCMAKE_BUILD_TYPE=Release
> > -DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX} -DLLVM_LIBDIR_SUFFIX=64", there is
> > no error during building process.
> >
> > And then I compile following c++ code using command "clang++ -std=c++11
> > -stdlib=libc++ -lc++abi -g t.cpp":
> > // t.cpp
> > #include 
> > using namespace std;
> > int main() {
> >string s = "aa";
> >cout << s;
> > }
> > Try lldb to debug a.out, found that I can't print string s which shows
> > empty:
> > lldb a.out
> > (lldb) target create "a.out"
> > Current executable set to 'a.out' (x86_64).
> > (lldb) l
> >4int main() {
> >5   string s = "aa";
> >6   cout << s;
> >7}
> > (lldb) b 6
> > Breakpoint 1: where = a.out`main + 94 at t.cpp:6, address =
> > 0x00400e5e
> > (lldb) r
> > Process 150 launched: '/root/a.out' (x86_64)
> > Process 150 stopped
> > * thread #1: tid = 150, 0x00400e5e a.out`main + 94 at t.cpp:6, name
> > = 'a.out', stop reason = breakpoint 1.1
> > frame #0: 0x00400e5e a.out`main + 94 at t.cpp:6
> >3using namespace std;
> >4int main() {
> >5   string s = "aa";
> > -> 6   cout << s;
> >7}
> > (lldb) p s
> > (std::__1::string) $0 = {}
> >
> > Could you please help point out what's wrong in my env? Thanks.
> >
> > Thanks,
> > Zhenglin
> >
> > ___
> > 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Auditing dotest's command line options

[Greg Clayton via lldb-dev]

Do we not want to have an "options" global variable in this module that 
contains everything instead of having separate global variables in this file? 
The idea would be that you could assign directly when parsing arguments:

(configuration.options, args) = parser.parse_args(sys.argv[1:])

Its OK if we don't do this, but this is what I was originally thinking. Then we 
don't need to do any transfer out of the options dictionary that is returned by 
the option parser. The drawback with this approach is the 
"configuration.options" would probably need to be initialized in case someone 
tries to access the "configuration.options" without first parsing arguments. So 
in that respect the global approach is nicer.

Greg

> On Dec 8, 2015, at 10:45 AM, Zachary Turner  wrote:
> 
> Hi Greg,
> 
> Take a look at dotest.py next time you get some free time and let me know 
> what you think.  There should be no more globals.  Everything that used to be 
> a global is now stored in its own module `configuration.py`, and everything 
> in `configuration.py` can be referenced from everywhere in the entire test 
> suite.
> 
> On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton  wrote:
> Zach, I would also like to get rid of all global variables in the process of 
> this change. The history goes like this: a long time ago someone wrote the 
> initial dotest.py and parsed the options manually and stored results in 
> global variables. Later, someone converted the options over to use a python 
> library to parse the options, but we mostly copied the options from the 
> options dictionary over into the globals and still use the globals all over 
> the code. It would be great if we had at most one global variable that is 
> something like "g_options" and anyone that was using any global variables 
> will switch over to use the "g_options." instead. Then we don't have to 
> make copies and we can let the g_options contain all settings that are 
> required.
> 
> > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev 
> >  wrote:
> >
> > I would like to do a complete audit of dotest's command line options, find 
> > out who's using what, and then potentially delete anything that isn't being 
> > used.  There's a mess of command line options in use, to the point that 
> > it's often hard to find free letters to use for new options.
> >
> > I created this spreadsheet with a complete list of command line options, 
> > their descriptions, and a place for people to enter what options they're 
> > using or do not want to be deleted.
> >
> > https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing
> >
> > If someone has already written YES in the box that indicates they need the 
> > option, please don't overwrite it.  If you write YES in a box, please 
> > provide at least a small rationale for why this option is useful to you.  
> > Feel free to add additional rationale if someone has already added some 
> > rationale.
> >
> > I'm going to have a couple days in mid-December and do this cleanup, so I'd 
> > like to get a solid picture of what options are not needed before then.  
> > After people have had some time to look over this, I'll go through the 
> > results and decide what to do with each one, and then send out another 
> > email with a proposed action column for each command line option.
> >
> > Please do take the time to have a look at this, because any option that 
> > doesn't have a YES in it after a couple of weeks I'm going to assume is a 
> > candidate for deletion.
> >
> >
> > ___
> > 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] Auditing dotest's command line options

[Greg Clayton via lldb-dev]

Sounds good, looks good then.

> On Dec 8, 2015, at 11:09 AM, Zachary Turner  wrote:
> 
> One advantage of this approach is that it makes the options available to the 
> entire test suite.  Even if we have no transferring going on, and we get 
> argparse to return us a perfectly organized structure with everything in the 
> right format, in order to make all the options accessible to the rest of the 
> test suite, we still need to stick it in a global module somewhere.  And then 
> you would write `configuration.options.test_categories`, whereas with this 
> approach we just write `configuration.test_categories`.  It's a minor point, 
> but I like the shorter member access personally.
> 
> On Tue, Dec 8, 2015 at 11:07 AM Zachary Turner  wrote:
> There's no way to avoid doing a transfer out of the options dictionary at 
> some level, because it's not a straight transfer.  There's a ton of 
> post-processing that gets done on the options dictionary in order to convert 
> the raw options into a useful format.
> 
> That might be solvable with more advanced use of argparse.  This approach 
> does get rid of one level of option transfer though.  Because we would 
> transfer
> 1. From the class returned by argparse into the global
> 2. From the global into the lldb module
> 
> Now we only transfer from the argparse class into the `configuration` module, 
> and everything else just uses that.
> 
> 
> On Tue, Dec 8, 2015 at 10:52 AM Greg Clayton  wrote:
> Do we not want to have an "options" global variable in this module that 
> contains everything instead of having separate global variables in this file? 
> The idea would be that you could assign directly when parsing arguments:
> 
> (configuration.options, args) = parser.parse_args(sys.argv[1:])
> 
> Its OK if we don't do this, but this is what I was originally thinking. Then 
> we don't need to do any transfer out of the options dictionary that is 
> returned by the option parser. The drawback with this approach is the 
> "configuration.options" would probably need to be initialized in case someone 
> tries to access the "configuration.options" without first parsing arguments. 
> So in that respect the global approach is nicer.
> 
> Greg
> 
> > On Dec 8, 2015, at 10:45 AM, Zachary Turner  wrote:
> >
> > Hi Greg,
> >
> > Take a look at dotest.py next time you get some free time and let me know 
> > what you think.  There should be no more globals.  Everything that used to 
> > be a global is now stored in its own module `configuration.py`, and 
> > everything in `configuration.py` can be referenced from everywhere in the 
> > entire test suite.
> >
> > On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton  wrote:
> > Zach, I would also like to get rid of all global variables in the process 
> > of this change. The history goes like this: a long time ago someone wrote 
> > the initial dotest.py and parsed the options manually and stored results in 
> > global variables. Later, someone converted the options over to use a python 
> > library to parse the options, but we mostly copied the options from the 
> > options dictionary over into the globals and still use the globals all over 
> > the code. It would be great if we had at most one global variable that is 
> > something like "g_options" and anyone that was using any global variables 
> > will switch over to use the "g_options." instead. Then we don't have to 
> > make copies and we can let the g_options contain all settings that are 
> > required.
> >
> > > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev 
> > >  wrote:
> > >
> > > I would like to do a complete audit of dotest's command line options, 
> > > find out who's using what, and then potentially delete anything that 
> > > isn't being used.  There's a mess of command line options in use, to the 
> > > point that it's often hard to find free letters to use for new options.
> > >
> > > I created this spreadsheet with a complete list of command line options, 
> > > their descriptions, and a place for people to enter what options they're 
> > > using or do not want to be deleted.
> > >
> > > https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing
> > >
> > > If someone has already written YES in the box that indicates they need 
> > > the option, please don't overwrite it.  If you write YES in a box, please 
> > > provide at least a small rationale for why this option is useful to you.  
> > > Feel free to add additional rationale if someone has already added some 
> > > rationale.
> > >
> > > I'm going to have a couple days in mid-December and do this cleanup, so 
> > > I'd like to get a solid picture of what options are not needed before 
> > > then.  After people have had some time to look over this, I'll go through 
> > > the results and decide what to do with each one, and then send out 
> > > another email with a proposed action column for each command line option.
> > >
> > > Please do take the time 

Re: [lldb-dev] Passing as argument an array in a function call

[Greg Clayton via lldb-dev]

Looks like this is a MIPS specific bug, probably something we aren't handling 
(relocation type maybe?) in the JITed code we produce:

This works fine on the MacOSX lldb:

(lldb) expr -- uint32_t data[6] = {}; test1(data);  data
(uint32_t [6]) $0 = ([0] = 0x002a, [1] = 0x002b, [2] = 0x002c, [3] 
= 0x002d, [4] = 0x002e, [5] = 0x002f)




> On Dec 16, 2015, at 6:06 AM, Dean De Leo via lldb-dev 
>  wrote:
> 
> Hi,
> 
> assume we wish to use the expression evaluator to invoke a function from 
> lldb, setting the result into an array passed as parameter, e.g:
> 
> void test1(uint32_t* d) {
>for(int i = 0; i < 6; i++){
>d[i] = 42 + i;
>}
> }
> 
> where the expected output should be d = {42,43,44,45,46,47}. However 
> performing the following expression having as target android/mips32 returns:
> 
> (lldb) expr -- uint32_t data[6] = {}; test1(data);  data
> (uint32_t [6]) $4 = ([0] = 0, [1] = 2003456944, [2] = 44, [3] = 45, [4] = 
> 2004491136, [5] = 47)
> 
> Is this an expected behaviour or a bug? I suspect the evaluator allocates the 
> memory for data and releases once the expression has been executed?
> 
> If so, can you please advise what's the proper way to achieve the same 
> functionality?
> 
> 
> Thanks,
> Dean
> ___
> 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] Passing as argument an array in a function call

[Greg Clayton via lldb-dev]

> On Dec 16, 2015, at 6:06 AM, Dean De Leo via lldb-dev 
>  wrote:
> 
> Hi,
> 
> assume we wish to use the expression evaluator to invoke a function from 
> lldb, setting the result into an array passed as parameter, e.g:
> 
> void test1(uint32_t* d) {
>for(int i = 0; i < 6; i++){
>d[i] = 42 + i;
>}
> }
> 
> where the expected output should be d = {42,43,44,45,46,47}. However 
> performing the following expression having as target android/mips32 returns:
> 
> (lldb) expr -- uint32_t data[6] = {}; test1(data);  data
> (uint32_t [6]) $4 = ([0] = 0, [1] = 2003456944, [2] = 44, [3] = 45, [4] = 
> 2004491136, [5] = 47)
> 
> Is this an expected behaviour or a bug?

Definitely a bug in LLDB somewhere, or possibly in the memory allocation on the 
MIPS host that is done via lldb-server. Are you using lldb-server here? It has 
an allocate memory packet.

> I suspect the evaluator allocates the memory for data and releases once the 
> expression has been executed?

We allocate memory for the resulting data that continues to exist in your 
process so the memory shouldn't be released.

> If so, can you please advise what's the proper way to achieve the same 
> functionality?

This should work so it will be a matter of tracking down what is actually 
failing. If you can run to where you want to run your expression and then 
before you run your expression do:

(lldb) log enable -f /tmp/log.txt gdb-remote packets
(lldb) log enable -f /tmp/log.txt lldb expr

Then run your expression and then do:

(lldb) log disable gdb-remote packets
(lldb) log disable lldb expr

Then send the file, we might be able to see what is going on. The GDB remote 
packets will allow us to see the memory that is allocated, and the "lldb expr" 
will allow us to see all of the gory details as to where it is trying to use 
"d".
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb -c corefile get segmentation fault on centos7

[Greg Clayton via lldb-dev]

Something is probably NULL, like maybe the register context from frame 1 or 
frame 2. Make this crash again and then switch to each frame and dump all of 
the local variables. 
> On Dec 20, 2015, at 9:30 PM, 陶征霖 via lldb-dev  wrote:
> 
> Hi,
> 
> I build llvm+clang+lldb 3.7 successfully on centos7, and lldb -p PID works 
> pretty well. However when I tried lldb -c corefile executable_bin, lldb 
> itself core dumpped. Attached the following core info which is debugged by 
> gdb:
> [root@dn-cn-controller-4fbd4 data1]# lldb -c a.corefile 
> /usr/local/myproject/bin/cnode
> (lldb) target create "/usr/local/myproject/bin/cnode" --core "a.corefile"
> Segmentation fault (core dumped)
> 
> And then I tried gdb to check the lldb call stack:
> (gdb) info threads
>   Id   Target Id Frame
>   3Thread 0x7f81c4795700 (LWP 64) 0x7f81c9ed46d5 in 
> pthread_cond_wait@@GLIBC_2.3.2 ()
>from /lib64/libpthread.so.0
>   2Thread 0x7f81ce580740 (LWP 59) 0x7f81c9ed46d5 in 
> pthread_cond_wait@@GLIBC_2.3.2 ()
>from /lib64/libpthread.so.0
> * 1Thread 0x7f81c3f94700 (LWP 65) 0x7f81cbe00630 in 
> lldb_private::ArchSpec::GetMachine() const ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> (gdb) bt
> #0  0x7f81cbe00630 in lldb_private::ArchSpec::GetMachine() const ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #1  0x7f81cc20458f in 
> RegisterContextPOSIX_x86::RegisterContextPOSIX_x86(lldb_private::Thread&, 
> unsigned int, lldb_private::RegisterInfoInterface*) () from 
> /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #2  0x7f81cc153a24 in 
> RegisterContextCorePOSIX_x86_64::RegisterContextCorePOSIX_x86_64(lldb_private::Thread&,
>  lldb_private::RegisterInfoInterface*, lldb_private::DataExtractor const&, 
> lldb_private::DataExtractor const&) ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #3  0x7f81cc151e5e in 
> ThreadElfCore::CreateRegisterContextForFrame(lldb_private::StackFrame*) ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #4  0x7f81cc1523b3 in ThreadElfCore::GetRegisterContext() ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #5  0x7f81cbfae9e2 in 
> lldb_private::StackFrameList::GetFramesUpTo(unsigned int) ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #6  0x7f81cbfaf3e7 in 
> lldb_private::StackFrameList::ResetCurrentInlinedDepth() ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #7  0x7f81cbfd32e2 in 
> lldb_private::Thread::ShouldStop(lldb_private::Event*) ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #8  0x7f81cbfd98d2 in 
> lldb_private::ThreadList::ShouldStop(lldb_private::Event*) ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #9  0x7f81cbf997bb in 
> lldb_private::Process::ShouldBroadcastEvent(lldb_private::Event*) ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #10 0x7f81cbf998a1 in 
> lldb_private::Process::HandlePrivateEvent(std::shared_ptr&)
>  ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #11 0x7f81cbf9a77a in lldb_private::Process::RunPrivateStateThread(bool) 
> ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #12 0x7f81cbdf7db2 in 
> lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) ()
>from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7
> #13 0x7f81c9ed0dc5 in start_thread () from /lib64/libpthread.so.0
> #14 0x7f81c91c821d in clone () from /lib64/libc.so.6
> 
> Any suggesstion about why lldb -c core dump?
> 
> Thanks,
> Zhenglin
> ___
> 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] lldb 340.4.119 unable to attach (El Capitan)

[Greg Clayton via lldb-dev]

If you ssh in you must enable developer mode one time per boot:

sudo /usr/sbin/DevToolsSecurity --enable

Then you should be able to debug. If you don't, it will popup a dialog box on 
the remote system that attempts to get authorization, but you will never see 
that in your SSH window...

Let me know if this helps.

Greg

> On Dec 26, 2015, at 3:53 AM, Andre Vergison via lldb-dev 
>  wrote:
> 
> Hi,
> I tried Jason Molenda’s test code on El Capitan, lldb-340.4.119 (Jason 
> Molenda via lldb-dev | 3 Oct 02:59 2015).
> I’m connected to a remote VM using ssh.
>  
> tst$ echo 'int main () { }' > /tmp/a.c
> tst$ xcrun clang /tmp/a.c -o /tmp/a.out
> tst$ xcrun lldb /tmp/a.out
> (lldb) target create "/tmp/a.out"
> Current executable set to '/tmp/a.out' (x86_64).
> (lldb) r
> error: process exited with status -1 (unable to attach)
> (lldb) run
> error: process exited with status -1 (unable to attach)
> (lldb) quit
> tst$ ps -ef|grep a.out
>   502 33174 1   0 12:20PM ttys0000:00.00 /tmp/a.out
>   502 33187 1   0 12:20PM ttys0000:00.00 /tmp/a.out
>  
> I can’t even kill those using kill -9.
>  
> What’s going on here?
>  
> I tried the above because in fact I had a process which a segmentation fault 
> 11, here’s what lldb makes out of the core dump:
>  
> txt$ lldb /cores/core.33158
> (lldb) target create "/cores/core.33158"
> warning: (x86_64) /cores/core.33158 load command 175 LC_SEGMENT_64 has a 
> fileoff
>  + filesize (0x31c57000) that extends beyond the end of the file 
> (0x31c56000), t
> he segment will be truncated to match
> warning: (x86_64) /cores/core.33158 load command 176 LC_SEGMENT_64 has a 
> fileoff
>  (0x31c57000) that extends beyond the end of the file (0x31c56000), ignoring 
> thi
> s section
> Current executable set to '/cores/core.33158' (x86_64).
> (lldb)
>  
> Is this related? Compiled with g++ :
>  
> tst$ g++ --version
> Configured with: --prefix=/Library/Developer/CommandLineTools/usr 
> --with-gxx-inc
> lude-dir=/usr/include/c++/4.2.1
> Apple LLVM version 7.0.2 (clang-700.1.81)
> Target: x86_64-apple-darwin15.0.0
> Thread model: posix
>  
> Thx,
> Andre
> ___
> 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] Patch for addressing format warnings on 32-bit

[Greg Clayton via lldb-dev]

Please do cast to 64 bit and user PRI*64 macros. %z isn't supported on all 
platforms and we need to get away from using it.

> On Dec 28, 2015, at 10:32 AM, William Dillon via lldb-dev 
>  wrote:
> 
> Hi Todd,
> 
> The example I put in my last email is one of a few (maybe one more) instances 
> where the existing code casts to 64-bit and uses PRIu64.  When I’m dabbling 
> in existing code I try to copy the conventions that are already in place, so 
> that’s why I went this way.  I’m happy to change it to %zu.  I was just 
> checking about that.
> 
> - Will
> 
>> On Dec 28, 2015, at 10:24 AM, Todd Fiala  wrote:
>> 
>> Hi William,
>> 
>> It looks like just the PRIx64/PRIu64 bits are needed from a visual 
>> inspection.  The source variables that are printed from already are 64-bit 
>> always, aren't they?  If they're not but they should be, that seems like the 
>> real underlying problem rather than needing to cast.
>> 
>> What kind of warning are you seeing if you just replace the % format 
>> specifier?
>> 
>> Thanks!
>> 
>> -Todd
>> 
>> On Sun, Dec 27, 2015 at 12:32 PM, William Dillon via lldb-dev 
>>  wrote:
>> > Message: 1
>> > Date: Sat, 26 Dec 2015 21:15:53 +0100
>> > From: Joerg Sonnenberger via lldb-dev 
>> > To: lldb-dev@lists.llvm.org
>> > Subject: Re: [lldb-dev] Patch for addressing format warnings on 32-bit
>> > Message-ID: <20151226201553.gb14...@britannica.bec.de>
>> > Content-Type: text/plain; charset=utf-8
>> >
>> > On Fri, Dec 25, 2015 at 06:34:09PM -0800, William Dillon via lldb-dev 
>> > wrote:
>> >> There are a handful of -Wformat warnings on 32-bit platforms.
>> >> I addressed all those that I’ve seen while working on Swift.
>> >> Let me know if the git diff format is inappropriate for this.
>> >
>> > Don't cast size_t to uint64_t, format it with %zu directly.
>> >
>> > Joerg
>> >
>> 
>> I can go ahead and do that, but I wonder whether there should be two 
>> different ways of handling this, even on the same line.  For example:
>> 
>> -error.SetErrorStringWithFormat ("SoftwareBreakpointr::%s 
>> addr=0x%" PRIx64 ": tried to read %lu bytes but only read %" PRIu64, 
>> __FUNCTION__, m_addr, m_opcode_size, (uint64_t)bytes_read);
>> +error.SetErrorStringWithFormat ("SoftwareBreakpointr::%s 
>> addr=0x%" PRIx64 ": tried to read %" PRIu64 " bytes but only read %" PRIu64, 
>> __FUNCTION__, m_addr, (uint64_t)m_opcode_size, (uint64_t)bytes_read);
>> 
>> - Will
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
>> 
>> 
>> -- 
>> -Todd
> 
> ___
> 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] lldb 340.4.119 unable to attach (El Capitan)

[Greg Clayton via lldb-dev]

> On Jan 5, 2016, at 1:11 AM, Andre Vergison  
> wrote:
> 
> Greg, I owe you a Bud (or fruit juice if you prefer) !!
> 
> That's all I had to do... Now it works like a charm!
> 
> tst$ sudo /usr/sbin/DevToolsSecurity --enable
> Developer mode is now enabled.
> tst$ lldb testabc
> (lldb) target create "testabc"
> Current executable set to 'testabc' (x86_64).
> (lldb) run
> Process 34322 launched: '/Users/tst/testabc' (x86_64)
> TESTING on  2016/01/05 09:53:25
> ...
> 
> And all lldb commands work nicely.
> Now disabling for a test:
> 
> tst$ sudo /usr/sbin/DevToolsSecurity --disable
> Developer mode is now disabled.
> tst$ lldb testabc
> (lldb) target create "testabc"
> Current executable set to 'testabc' (x86_64).
> (lldb) run
> error: process exited with status -1 (unable to attach)
> (lldb) quit
> 
> So that was definitely the (only) reason.

Great!

> 
> Perhaps this 'developer mode' is something natural in the eyes of Mac 
> developers. I do porting on multiple systems, I'm becoming more and more 
> familiar with Mac every day, and I was not fully aware of the switch, the 
> more that lldb ran 'almost' normally.

It is for security reasons that is has been added. 

> Wouldn't it be an idea to add to lldb a warning against missing developer 
> mode rather than exhibiting its odd 'unable to attach' and zombie creation 
> behavior? Even as 'developer' I still was not able to kill the zombie I 
> created per the above 'developer disabled' lldb session.
> So how about:
> 
> (lldb) run
> error: developer mode not enabled

We should be able to do this. The main issue is detecting that the user is in a 
remote scenario where they don't have access to the UI. A dialog box will be 
popped up if the user is on the system, but when remotely connected we would 
need to detect this and return a correct error. This is a little harder as well 
because "debugserver", our GDB remote protocol debug stub, is what is 
requesting the debugging privelege. This is a program that is spawned by LLDB 
as a child process. But is should be able to be done somehow.

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

Re: [lldb-dev] How to load core on a different machine?

[Greg Clayton via lldb-dev]

Try this:

% lldb
(lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux
(lldb) 

If this works, there are SBPlatform class calls in the API you can use the 
select the platform as done above if you need to not do this from the command 
line.

The other option is to chroot into /path/to/remote/shared/libraries and you 
will need to copy your core file into /path/to/remote/shared/libraries, then 
just run LLDB normally and it should work.

Greg Clayton

> On Jan 5, 2016, at 12:53 PM, Eugene Birukov via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I am using LLDB-3.7 on Ubuntu Linux.
> 
> I have a core dump file and all shared libraries from my server but I want to 
> investigate them on a dev box. But I fail to correctly load it in LLDB - it 
> shows wrong stacks. I.e. I am looking for something equivalent to GDB 
> commands "set solib-absolute-prefix" and "set solib-search-path".
> 
> I tried to play with "target modules search-paths insert", but I cannot use 
> it if there is no target and I cannot load core after I have a target - not 
> sure what this command is intended to do...
> 
> Now, what I really need to do - it is load core in my custom debugger that 
> uses C++ API. Here I made some progress:
>   • Create target with NULL file name
>   • Load core using SBTarget::LoadCore()
>   • Manually load all executables - the initial a.out and all the shared 
> libraries using SBTarget::AddModule() and SBTarget::SetModuleLoadAddress()
> This kind of works, but there are two problems:
>   • How would I find the list of modules and addresses to load from the 
> core file? Currently I did it by loading core in the debugger on the server, 
> but this is not acceptable for production run...
>   • LLDB correctly prints stacks and resolves symbols, but I cannot 
> disassembly any code - the ReadMemory retuns all zeroes from code addresses.
> 
> Any help would be greatly appreciated.
> 
> Thanks,
> Eugene
> ___
> 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] How to load core on a different machine?

[Greg Clayton via lldb-dev]

So this should work:

(lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux
(lldb) 

So you need to make sure that your sysroot ("/path/to/remote/shared/libraries") 
contains files as they would appear on the remote system with the right paths 
("/usr/lib/libc.so" should be in 
"/path/to/remote/shared/libraries/usr/lib/libc.so"). If that is true and you 
still are getting the wrong stack backtraces, then there are bugs in LLDB 
possibly in ProcessElfCore or possibly in DynamicLoaderPOSIXDYLD. What should 
happen is when we are asked to find "/usr/lib/libc.so", the platform that is 
selected should be the one that is asked to find "/usr/lib/libc.so", and it 
should check if the platform has a sysroot (like 
"/path/to/remote/shared/libraries") and it should prepend this when looking for 
"/usr/lib/libc.so", so it should be checking 
"/path/to/remote/shared/libraries/usr/lib/libc.so". So you will need to step 
through Target::GetSharedModule() and see what is going wrong. 

If that still fails, it seems we do have a way around this with the "target 
modules search-paths add" command:

(lldb) target modules search-paths add /usr/lib /tmp

So if you have "/usr/lib/libc.so", it should look in "/tmp/libc.so". But I 
would prefer it if we get this working by the platform method by debugging what 
is going wrong in Target::GetSharedModule(). The target has a platform and it 
should consult the platform when asked to find a module given a ModuleSpec. The 
ModuleSpec contains the path, and optionally the architecture and UUID. If any 
code in ProcessElfCore or DynamicLoaderPOSIXDYLD is not using 
Target::GetSharedModule(), then that might be the bug (code should never just 
call the static ModuleList::GetSharedModule() to locate files for a target.

Let me know what you come up with,

Greg Clayton



> On Jan 6, 2016, at 11:03 AM, Eugene Birukov  wrote:
> 
> Hmm... neither approach really works. 
> 
> 1. I created platform from lldb prompt, but when I create target from core 
> file I see exactly the same wrong stacks. It seems that platform is ignored 
> during core load in my case.
> 2. chroot requires the whole set of binaries there in the new root. I simply 
> cannot copy everything from the server. Even if I do, lldb will use copied 
> binaries which is not a good idea...
> 
> root@eugenebi-L2:~# chroot /home/eugene/tmp
> chroot: failed to run command ‘/bin/bash’: No such file or directory
> 
> 3. I tried SBDebugger::SetCurrentPlatformSDKRoot() but it does not have any 
> visible effect on load core, not sure what it is supposed to do :)
> 
> Eugene
> 
> > Subject: Re: [lldb-dev] How to load core on a different machine?
> > From: gclay...@apple.com
> > Date: Tue, 5 Jan 2016 15:04:36 -0800
> > CC: lldb-dev@lists.llvm.org
> > To: eugen...@hotmail.com
> > 
> > Try this:
> > 
> > % lldb
> > (lldb) platform select --sysroot /path/to/remote/shared/libraries 
> > remote-linux
> > (lldb) 
> > 
> > If this works, there are SBPlatform class calls in the API you can use the 
> > select the platform as done above if you need to not do this from the 
> > command line.
> > 
> > The other option is to chroot into /path/to/remote/shared/libraries and you 
> > will need to copy your core file into /path/to/remote/shared/libraries, 
> > then just run LLDB normally and it should work.
> > 
> > Greg Clayton
> > 
> > > On Jan 5, 2016, at 12:53 PM, Eugene Birukov via lldb-dev 
> > >  wrote:
> > > 
> > > Hi,
> > > 
> > > I am using LLDB-3.7 on Ubuntu Linux.
> > > 
> > > I have a core dump file and all shared libraries from my server but I 
> > > want to investigate them on a dev box. But I fail to correctly load it in 
> > > LLDB - it shows wrong stacks. I.e. I am looking for something equivalent 
> > > to GDB commands "set solib-absolute-prefix" and "set solib-search-path".
> > > 
> > > I tried to play with "target modules search-paths insert", but I cannot 
> > > use it if there is no target and I cannot load core after I have a target 
> > > - not sure what this command is intended to do...
> > > 
> > > Now, what I really need to do - it is load core in my custom debugger 
> > > that uses C++ API. Here I made some progress:
> > > • Create target with NULL file name
> > > • Load core using SBTarget::LoadCore()
> > > • Manually load all executables - the initial a.out and all the shared 
> > > libraries using SBTarget::AddModule() and SBTarget::SetModuleLoadAddress()
> > > This kind of works, but there are two problems:
> > > • How would I find the list of modules and addresses to load from the 
> > > core file? Currently I did it by loading core in the debugger on the 
> > > server, but this is not acceptable for production run...
> > > • LLDB correctly prints stacks and resolves symbols, but I cannot 
> > > disassembly any code - the ReadMemory retuns all zeroes from code 
> > > addresses.
> > > 
> > > Any help would be greatly appreciated.
> > > 
> > > Thanks,
> > > Eugene
> > > __

Re: [lldb-dev] How to load core on a different machine?

[Greg Clayton via lldb-dev]

> On Jan 6, 2016, at 3:39 PM, Eugene Birukov  wrote:
> 
> OK, I'll try to see what happens with the platform. The truth is that shipped 
> lldb-3.7.0 does not load core on Linux at all and I am using custom version 
> that has been patched (by restoring some 3.6.0 code). So, there might be a 
> problem there.
> 
> Meanwhile, I found a way around. In my C++ code I do this:
> 
> m_Target = m_Debugger.CreateTarget(target);
> m_Debugger.HandleCommand("target modules search-paths add 
> /lib/x86_64-linux-gnu /home/eugene/tmp");
> m_Debugger.HandleCommand("target modules search-paths add 
> /usr/lib/x86_64-linux-gnu /home/eugene/tmp");
> m_Process = m_Target.LoadCore(core);
> 
> This does get the stacks right. Still, I have a problem with it: when I try 
> to disassemble the code, it is all zeroes. Any advice where I should look to 
> figure out what's wrong?

You can check ProcessElfCore::DoReadMemory() to see what happens when it reads 
the memory it is trying to disassemble. What you type "disassemble --frame", it 
will try and read the memory from the process (and instance of ProcessElfCore) 
and the memory read will try to read the data from the core memory. Make sure 
this is correctly accessing the memory and getting non-zeroes back from the 
memory read. Anything that was mapped into the process should be saved in the 
core file and be available to read as valid memory. 

What does the output of "image list" show? It should show the load addresses of 
all the shared libraries as the location that it was loaded when the core file 
was made. If you see a bunch of zeros as the load location, then maybe the 
shared libraries aren't getting loaded correctly?

> Also, if I iterate loaded modules, all of the shared libraries are mentioned 
> twice, which doesn't look right:
> 
> Modules: 20
> (x86_64) /home/eugene/tmp/a.out
> (x86_64) /home/eugene/tmp/libpthread.so.0
> (x86_64) /home/eugene/tmp/librt.so.1
> (x86_64) /home/eugene/tmp/libdl.so.2
> (x86_64) /home/eugene/tmp/libjemalloc.so.1
> (x86_64) /home/eugene/tmp/libc++.so.1
> (x86_64) /home/eugene/tmp/libm.so.6
> (x86_64) /home/eugene/tmp/libgcc_s.so.1
> (x86_64) /home/eugene/tmp/libc.so.6
> (x86_64) /home/eugene/tmp/ld-linux-x86-64.so.2
> (x86_64) /home/eugene/tmp/libpthread.so.0
> (x86_64) /home/eugene/tmp/librt.so.1
> (x86_64) /home/eugene/tmp/libdl.so.2
> (x86_64) /home/eugene/tmp/libjemalloc.so.1
> (x86_64) /home/eugene/tmp/libc++.so.1
> (x86_64) /home/eugene/tmp/libm.so.6
> (x86_64) /home/eugene/tmp/libgcc_s.so.1
> (x86_64) /home/eugene/tmp/libc.so.6
> (x86_64) /home/eugene/tmp/libunwind.so.8
> (x86_64) /home/eugene/tmp/liblzma.so.5

That is probably your problem... The first copy is probably not loaded, but the 
second one is? It will be interesting to see what the output of the "image 
list" command shows. The first one might claim 0x0 as the load location and the 
second one might be valid. This seems like this is a bug in the dynamic loader 
plugin (DynamicLoaderPOSIXDYLD). So try to figure out why two copies are 
getting added and then make sure they are loaded at valid non-overlapping 
addresses.

> Eugene

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

Re: [lldb-dev] How to load core on a different machine?

[Greg Clayton via lldb-dev]

> On Jan 6, 2016, at 4:34 PM, Eugene Birukov  wrote:
> 
> Correction: platform trick almost works. For some reason two libraries are 
> not affected, but the rest are OK. 
> Hmm... image list does not have load addresses.

Does something show when you just debug something on linux like /bin/ls? Try 
doing:

(lldb) file /bin/ls
(lldb) b malloc
(lldb) r
(lldb) image list

Maybe Linux hasn't implemented this yet.

> I'll trace what read memory does... Does the core contain this memory or is 
> it loaded from the library file?

It should try to read any memory that it tracks down from the core file if it 
is available. It should try to fall back to reading from the library file if 
the memory read fails from the core.


> 
> eugene@EUGENEBI-L1:~/tmp$ ~/llvm-1-Release/bin/lldb-3.7.0
> (lldb) platform select --sysroot ~/tmp/x remote-linux
>   Platform: remote-linux
>  Connected: no
> (lldb) target create a.out -c core.36736
> Core file '/home/eugene/tmp/core.36736' (x86_64) was loaded.
> (lldb) bt
> * thread #1: tid = 36737, 0x7fd696af1b13 libc.so.6`epoll_wait + 51
>   * frame #0: 0x7fd696af1b13 libc.so.6`epoll_wait + 51
> frame #1: 0x7fd6980bde4b 
> palrun`epoll_thread_func((null)=0x) + 43 at sockets.cpp:773
> frame #2: 0x7fd697c12182 libpthread.so.0`start_thread + 194
> frame #3: 0x7fd696af147d libc.so.6`clone + 109
> (lldb) image list
> [  0] AB5E3D5B-4CFF-A55B-3A81-C7DD1E76DDEC-24786ADE
> /home/eugene/tmp/a.out
> [  1] 9318E8AF-0BFB-E444-731B-B0461202EF57-F7C39542
> /home/eugene/tmp/libpthread.so.0
> [  2] 92FCF41E-FE01-2D61-86E3-1A59AD05BDBB-487769AB
> /home/eugene/tmp/librt.so.1
> [  3] C1AE4CB7-195D-337A-77A3-C689051DABAA-3980CA0C
> /home/eugene/tmp/libdl.so.2
> [  4] B18D9892-DF6A-E4E9-48BA-0FE2FBDDD200-95730E73
> /home/eugene/tmp/libjemalloc.so.1
> [  5] 9FDCDABA-45B5-5C28-D057-7C9B96A75CC7-73D83B3B
> /home/eugene/tmp/libc++.so.1
> [  6] 1D76B71E-905C-B867-B27C-EF230FCB20F0-1A3178F5
> /home/eugene/tmp/libm.so.6
> [  7] 8D0AA714-1158-0EE6-C088-09695C398476-9F25725B
> /home/eugene/tmp/libgcc_s.so.1
> [  8] 30C94DC6-6A1F-E951-80C3-D68D2B89E576-D5AE213C
> /home/eugene/tmp/libc.so.6
> [  9] 9F00581A-B3C7-3E3A-EA35-995A0C50D24D-59A01D47
> /home/eugene/tmp/ld-linux-x86-64.so.2
> [ 10] 9318E8AF-0BFB-E444-731B-B0461202EF57-F7C39542
> /home/eugene/tmp/libpthread.so.0
> [ 11] 92FCF41E-FE01-2D61-86E3-1A59AD05BDBB-487769AB
> /home/eugene/tmp/librt.so.1
> [ 12] C1AE4CB7-195D-337A-77A3-C689051DABAA-3980CA0C
> /home/eugene/tmp/libdl.so.2
> [ 13] B18D9892-DF6A-E4E9-48BA-0FE2FBDDD200-95730E73
> /home/eugene/tmp/libjemalloc.so.1
> [ 14] 9FDCDABA-45B5-5C28-D057-7C9B96A75CC7-73D83B3B
> /home/eugene/tmp/libc++.so.1
> [ 15] 1D76B71E-905C-B867-B27C-EF230FCB20F0-1A3178F5
> /home/eugene/tmp/libm.so.6
> [ 16] 8D0AA714-1158-0EE6-C088-09695C398476-9F25725B
> /home/eugene/tmp/libgcc_s.so.1
> [ 17] 30C94DC6-6A1F-E951-80C3-D68D2B89E576-D5AE213C
> /home/eugene/tmp/libc.so.6
> [ 18] 11E7491E-E391-903D-EE47-1D098DD64A94-D4F3553F
> /usr/lib/x86_64-linux-gnu/libunwind.so.8
> [ 19] 15AED485-5920-E5A0-FB87-91B683EB88C7-E1199260
> /lib/x86_64-linux-gnu/liblzma.so.5
> (lldb) disas --frame
> libc.so.6`epoll_wait:
> 0x7fd696af1ae0 <+0>:  addb   %al, (%rax)
> 0x7fd696af1ae2 <+2>:  addb   %al, (%rax)
> 0x7fd696af1ae4 <+4>:  addb   %al, (%rax)
> 0x7fd696af1ae6 <+6>:  addb   %al, (%rax)
> 0x7fd696af1ae8 <+8>:  addb   %al, (%rax)
> 0x7fd696af1aea <+10>: addb   %al, (%rax)
> ...
> 
> Eugene
> 
> 
> > Subject: Re: [lldb-dev] How to load core on a different machine?
> > From: gclay...@apple.com
> > Date: Wed, 6 Jan 2016 16:21:22 -0800
> > CC: lldb-dev@lists.llvm.org
> > To: eugen...@hotmail.com
> > 
> > 
> > > On Jan 6, 2016, at 3:39 PM, Eugene Birukov  wrote:
> > > 
> > > OK, I'll try to see what happens with the platform. The truth is that 
> > > shipped lldb-3.7.0 does not load core on Linux at all and I am using 
> > > custom version that has been patched (by restoring some 3.6.0 code). So, 
> > > there might be a problem there.
> > > 
> > > Meanwhile, I found a way around. In my C++ code I do this:
> > > 
> > > m_Target = m_Debugger.CreateTarget(target);  
> > > m_Debugger.HandleCommand("target modules search-paths add 
> > > /lib/x86_64-linux-gnu /home/eugene/tmp");
> > > m_Debugger.HandleCommand("target modules search-paths add 
> > > /usr/lib/x86_64-linux-gnu /home/eugene/tmp");
> > > m_Process = m_Target.LoadCore(core);
> > > 
> > > This does get the stacks right. Still, I have a problem with it: when I 
> > > try to disassemble the code, it is all zeroes. Any advice where I shoul

Re: [lldb-dev] How to load core on a different machine? - image base addresses

[Greg Clayton via lldb-dev]

> On Jan 7, 2016, at 9:02 AM, Eugene Birukov  wrote:
> 
> Forking the thread since image list looks like an independent issue.
> 
>   • There is no image base addresses on Linux. Is this a known issue? 

It is now!

>   • I did not find any C++ API to get it in my program. Did I miss it? 
> Seems useful...

The main question is what do you consider to be your "image address"? For MachO 
files on MacOSX, it is the address of the mach header in memory. If the ELF 
header and all of the program headers and sections headers are actually in 
memory, then the address should be the address of the ELF header.

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

Re: [lldb-dev] How to load core on a different machine? - image base addresses

[Greg Clayton via lldb-dev]

> On Jan 7, 2016, at 9:48 AM, Eugene Birukov  wrote:
> 
> > It is now!
> 
> Good :). Any plans to fix it? I guess I should just file a bug, right?
> 

Please file a bug. Someone probably will from the linux community, possibly 
even you?

> > The main question is what do you consider to be your "image address"?
> 
> I need the address that I feed to SBTarget::SetModuleLoadAddress() if I load 
> modules manually.
> 
> I iterated over module sections. As I understand, the base address  is 
> 0x7fc7125ff000. I verified it by really calling SetModuleLoadAddress() and 
> looking at stacks that LLDB produces. But to find it programmatically I'll 
> need to do some math: pick any section with non-zero size and subtract its 
> file address form its memory address. Hmm... seems like a workaround, but it 
> would be better to have a more direct way.
> 
> (x86_64) /home/eugene/joe/so/libjemalloc.so.1
> 0x [0x-0x) libjemalloc.so.1.
> 0x7fc7125ff200 [0x0200-0x0224) 
> libjemalloc.so.1..note.gnu.build-id
> 0x7fc7125ff228 [0x0228-0x0328) 
> libjemalloc.so.1..gnu.hash
> 0x7fc7125ff328 [0x0328-0x0b08) 
> libjemalloc.so.1..dynsym
> 0x7fc7125ffb08 [0x0b08-0x0f01) 
> libjemalloc.so.1..dynstr
> 0x7fc7125fff02 [0x0f02-0x0faa) 
> libjemalloc.so.1..gnu.version
> 0x7fc7125fffb0 [0x0fb0-0x1040) 
> libjemalloc.so.1..gnu.version_r
> 0x7fc712600040 [0x1040-0x2c00) 
> libjemalloc.so.1..rela.dyn
> 0x7fc712601c00 [0x2c00-0x3008) 
> libjemalloc.so.1..rela.plt
> 0x7fc712602008 [0x3008-0x3022) libjemalloc.so.1..init
> 0x7fc712602030 [0x3030-0x32f0) libjemalloc.so.1..plt
> 0x7fc7126022f0 [0x32f0-0x000286fa) libjemalloc.so.1..text
> 0x7fc7126276fc [0x000286fc-0x00028705) libjemalloc.so.1..fini
> 0x7fc712627740 [0x00028740-0x0002a344) 
> libjemalloc.so.1..rodata
> 0x7fc712629344 [0x0002a344-0x0002afa0) 
> libjemalloc.so.1..eh_frame_hdr
> 0x7fc712629fa0 [0x0002afa0-0x0002fdcc) 
> libjemalloc.so.1..eh_frame
> 0x7fc71282f710 [0x00230710-0x00230714) libjemalloc.so.1..tdata
> 0x7fc71282f718 [0x00230718-0x00230748) libjemalloc.so.1..tbss
> 0x7fc71282f718 [0x00230718-0x00230728) 
> libjemalloc.so.1..init_array
> 0x7fc71282f728 [0x00230728-0x00230730) 
> libjemalloc.so.1..fini_array
> 0x7fc71282f730 [0x00230730-0x00230738) libjemalloc.so.1..jcr
> 0x7fc71282f740 [0x00230740-0x00231d70) 
> libjemalloc.so.1..data.rel.ro
> 0x7fc712830d70 [0x00231d70-0x00231f70) 
> libjemalloc.so.1..dynamic
> 0x7fc712830f70 [0x00231f70-0x00232000) libjemalloc.so.1..got
> 0x7fc712831000 [0x00232000-0x00232170) 
> libjemalloc.so.1..got.plt
> 0x7fc712831180 [0x00232180-0x00232209) libjemalloc.so.1..data
> 0x7fc712831220 [0x00232220-0x002334b0) libjemalloc.so.1..bss
> 0x [0x-0x) 
> libjemalloc.so.1..gnu_debuglink
> 0x [0x-0x) 
> libjemalloc.so.1..shstrtab

So try the following:

(lldb) memory read 0x7fc7125ff000

See if you see the "ELF\x7d" magic byte string. If so, then this is definitely 
the address you are looking for. You can also set a breakpoint when the shared 
libraries get loaded and see where the image is being loaded since I believe 
the POSIX Dynamic Loader loads things using a single address that it gets from 
somewhere. This address that is used by the dynamic loader should be the 
address that is displayed...

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

Re: [lldb-dev] Using control+left/right arrow to jump between words in the prompt

[Greg Clayton via lldb-dev]

So anything that is missing can be added to your ~/.editrc file since LLDB uses 
the editline library and that reads .editrc file.

Examples of what you can add to your .editrc file:

lldb:bind '^[[5C' vi-next-word
lldb:bind '^[[5D' vi-prev-word
lldb:bind '^D' ed-delete-next-char
lldb:bind '^B' ed-command
lldb:bind '^P' ed-search-prev-history
lldb:bind '^N' ed-search-next-history

For more info, just type "man editrc" at your shell command line.

If you think any such bindings should be included by default, please file a bug 
and suggest what you think should be added by default. If you do add something 
you should think if the binding should be for vi or emacs bindings by default 
as these bindings often would differ between the two.

> On Jan 9, 2016, at 12:06 PM, Ori Avtalion via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I tried using lldb (and the Swift repl, which uses it), and found it
> very annoying that the CTRL+left/right arrow key sequence isn't
> handled correctly, spewing ;5D and ;5C instead.
> 
> I'm used to be able to hit Ctrl+left/right to jump between words in
> almost any editing software.
> 
> Is it a feature that would be welcome?
> 
> Thanks,
> Ori
> ___
> 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] Get source-map from python API?

[Greg Clayton via lldb-dev]

That being said, feel free to add something the SB API and propose a patch.

Greg

> On Jan 14, 2016, at 3:13 PM, Jim Ingham via lldb-dev 
>  wrote:
> 
> There is currently no API to access the settings.  You have to cons up 
> commands and use SBCommandInterpreter::HandleCommand to execute them.
> 
> This is one of the remaining holes in the SB API.
> 
> Jim
> 
>> On Jan 14, 2016, at 2:41 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> We are building an IDE debugger on top of lldb python API. In order to get 
>> the source remapping work(the source path embedded in the symbol may be 
>> different from the real source path), user needs to use "settings set 
>> target.source-map" command to remap the source. 
>> 
>> I would like users to do similar thing from our IDE debugger. However, I 
>> could not find a python API to specify the source remapping, and more 
>> important a way to access the remapping functionality. The SBSourceManager 
>> class only exposes a single DisplaySourceLinesWithLineNumbers() method which 
>> displays the source in console output. Ideally it should expose an API in 
>> SBSourceManager for us to provide the old FileSpec and get back a new 
>> remapped FileSpec.
>> 
>> Is this not exposed in Python API? Do I need to re-do the remapping logic in 
>> our IDE UI code? How is other IDE handling the source remapping?
>> 
>> Thanks
>> Jeffrey
>> 
>> ___
>> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Get source-map from python API?

[Greg Clayton via lldb-dev]

> On Jan 19, 2016, at 10:58 AM, Jim Ingham  wrote:
> 
> If you mean "Add an API that sets the source-map for a target" say to 
> SBTarget, then that sounds great.  

Indeed this is what I meant to say. Add an API to SBTarget that allows you to 
modify the source map.
> 
> But if we're going to add an API to get at settings in general, then we 
> should talk about it more broadly before anybody gets started.  There was a 
> bunch of stuff that we wanted to do with settings that we never got around 
> to, but still want to do.  In particular, we had intended some as yet 
> unspecified syntax for restricting settings to particular scenarios.  Not 
> this, but something like:
> 
> settings set target[OS=OSX].expr-prefix my_osx_prefix.h
> 
> gives you an idea of what we had in mind.  I'd rather not add a full on API 
> for the settings till we decide either how we want to do this (which I think 
> would be worth the effort but I don't think any of us have got time to 
> address this right now) or to scrap it and go with flat settings.

Settings setting should be exposed only as accessors on the objects themselves 
and not in a generic way that allows you to set settings via the API that takes 
the setting name. 

So in general I vote to always add accessors on the objects and avoid anyone 
playing with settings by name and/or string values.
> 
> Jim
> 
> 
>> On Jan 15, 2016, at 11:28 AM, Greg Clayton  wrote:
>> 
>> That being said, feel free to add something the SB API and propose a patch.
>> 
>> Greg
>> 
>>> On Jan 14, 2016, at 3:13 PM, Jim Ingham via lldb-dev 
>>>  wrote:
>>> 
>>> There is currently no API to access the settings.  You have to cons up 
>>> commands and use SBCommandInterpreter::HandleCommand to execute them.
>>> 
>>> This is one of the remaining holes in the SB API.
>>> 
>>> Jim
>>> 
 On Jan 14, 2016, at 2:41 PM, Jeffrey Tan via lldb-dev 
  wrote:
 
 Hi,
 
 We are building an IDE debugger on top of lldb python API. In order to get 
 the source remapping work(the source path embedded in the symbol may be 
 different from the real source path), user needs to use "settings set 
 target.source-map" command to remap the source. 
 
 I would like users to do similar thing from our IDE debugger. However, I 
 could not find a python API to specify the source remapping, and more 
 important a way to access the remapping functionality. The SBSourceManager 
 class only exposes a single DisplaySourceLinesWithLineNumbers() method 
 which displays the source in console output. Ideally it should expose an 
 API in SBSourceManager for us to provide the old FileSpec and get back a 
 new remapped FileSpec.
 
 Is this not exposed in Python API? Do I need to re-do the remapping logic 
 in our IDE UI code? How is other IDE handling the source remapping?
 
 Thanks
 Jeffrey
 
 ___
 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Inquiry for performance monitors

[Greg Clayton via lldb-dev]

One thing to think about is you can actually just run an expression in the 
program that is being debugged without needing to change anything in the GDB 
remote server. So this can all be done via python commands and would require no 
changes to anything. So you can run an expression to enable the buffer. Since 
LLDB supports multiple line expression that can define their own local 
variables and local types. So the expression could be something like:

int perf_fd = (int)perf_event_open(...);
struct PerfData
{
void *data;
size_t size;
};
PerfData result = read_perf_data(perf_fd);
result


The result is then a structure that you can access from your python command (it 
will be a SBValue) and then you can read memory in order to get the perf data.

You can also split things up into multiple calls where you can run 
perf_event_open() on its own and return the file descriptor:

(int)perf_event_open(...)

This expression will return the file descriptor

Then you could allocate memory via the SBProcess:

(void *)malloc(1024);

The result of this expression will be the buffer that you use...

Then you can read 1024 bytes at a time into this newly created buffer.

So a solution that is completely done in python would be very attractive.

Greg


> On Jan 21, 2016, at 7:04 AM, Ravitheja Addepally  
> wrote:
> 
> Hello,
>   Regarding the questions in this thread please find the answers ->
> 
> How are you going to present this information to the user? (I know
> debugserver can report some performance data... Have you looked into
> how that works? Do you plan to reuse some parts of that
> infrastructure?) and How will you get the information from the server to the 
> client?
> 
>  Currently I plan to show a list of instructions that have been executed so 
> far, I saw the
> implementation suggested by pavel, the already present infrastructure is a 
> little bit lacking in terms of the needs of the
> project, but I plan to follow a similar approach, i.e to extract the raw 
> trace data by querying the server (which can use the
> perf_event_open to get the raw trace data from the kernel) and transport it 
> through gdb packets ( qXfer packets
> https://sourceware.org/gdb/onlinedocs/gdb/Branch-Trace-Format.html#Branch-Trace-Format).
>  At the client side the raw trace data
> could be passed on to python based command that could decode the data. This 
> also eliminates the dependency of libipt since LLDB 
> would not decode the data itself.
> 
> There is also the question of this third party library.  Do we take a hard 
> dependency on libipt (probably a non-starter), or only use it if it's 
> available (much better)?
> 
> With the above mentioned way LLDB would not need the library, who ever wants 
> to use the python command would have to install it separately but LLDB wont 
> need it
> 
> With the performance counters, the interface would still be perf_event_open, 
> so if there was a perf_wrapper in LLDB server then it could be reused to 
> configure and use the
> software performance counters as well, you would just need to pass different 
> attributes in the perf_event_open system call, plus I think the perf_wrapper 
> could be reused to
> get CoreSight information as well (see https://lwn.net/Articles/664236/ )
> 
> 
> On Wed, Oct 21, 2015 at 8:57 PM, Greg Clayton  wrote:
> one main benefit to doing this externally is allow this to be done remotely 
> over any debugger connection. If you can run expressions to 
> enable/disable/setup the memory buffer/access the buffer contents, then you 
> don't need to add code into the debugger to actually do this.
> 
> Greg
> 
> > On Oct 21, 2015, at 11:54 AM, Greg Clayton  wrote:
> >
> > IMHO the best way to provide this information is to implement reverse 
> > debugging packets in a GDB server (lldb-server). If you enable this feature 
> > via some packet to lldb-server, and that enables the gathering of data that 
> > keeps the last N instructions run by all threads in some buffer that gets 
> > overwritten. The lldb-server enables it and gives a buffer to the 
> > perf_event_interface(). Then clients can ask the lldb-server to step back 
> > in any thread. Only when the data is requested do we actually use the data 
> > to implement the reverse stepping.
> >
> > Another way to do this would be to use a python based command that can be 
> > added to any target that supports this. The plug-in could install a set of 
> > LLDB commands. To see how to create new lldb command line commands in 
> > python, see the section named "CREATE A NEW LLDB COMMAND USING A PYTHON 
> > FUNCTION" on the http://lldb.llvm.org/python-reference.html web page.
> >
> > Then you can have some commands like:
> >
> > intel-pt-start
> > intel-pt-dump
> > intel-pt-stop
> >
> > Each command could have options and arguments as desired. The 
> > "intel-pt-start" command could make an expression call to enable the 
> > feature in the target by running and expression that runs the some 
> > perf_e

Re: [lldb-dev] Inquiry for performance monitors

[Greg Clayton via lldb-dev]

> On Feb 4, 2016, at 2:24 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> On 4 February 2016 at 10:04, Ravitheja Addepally
>  wrote:
>> Hello Pavel,
>>In the case of expression evaluation approach you mentioned
>> that:
>> 1. The data could be accessible only when the target is stopped. why is that
>> ?
> If I understand the approach correctly, the idea is the run all perf
> calls as expressions in the debugger. Something like
> lldb> expr perf_event_open(...)
> We need to stop the target to be able to do something like that, as we
> need to fiddle with its registers. I don't see any way around that...
> 
>> 2. What sort of noise were you referring to ?
> Since now all the perf calls will be expressions executed within the
> context of the process being traced, they themselves will show up in
> the trace. I am sure we could filter that out somehow, but it feels
> like an added complication..
> 
> Does that make it any clearer?

So a few questions: people seem worried about running something in the process 
if expression are being used. Are you saying that if the process is on the 
local machine, process 1 can just open up a file descriptor to the trace data 
for process 2? If so, why pass this through lldb-server? I am not a big fan 
making the lldb-server become the conduits for a ton of information. It just 
isn't built for that high volumes of data coming in. I can be done, but that 
doesn't mean it should. If everyone starts passing data like memory usage, CPU 
time, trace info, backtraces and more through asynchronously through 
lldb-server, it will become a very crowded communication channel. 

You don't need python if you want to do this using the lldb API. If your IDE is 
already linking against the LLDB shared library, it can just run the 
expressions using the public LLDB API. This is how view debugging is 
implemented in Xcode. It runs complex expressions that gather all data about a 
view and its subviews and returns all the layers in a blob of data that can be 
serialized by the expression, retrieved by Xcode (memory read from the 
process), and then de-serialized by the IDE into a format that can be used. If 
your IDE can access the trace data for another process, why not just read it 
from the IDE itself? Why get the lldb-server involved? Granted the remote 
debugging parts of this make an argument for including it in the lldb-server. 
But if you go this route you need to make a base implementation for trace data 
that will work for any trace data, have trace data plug-ins that somehow know 
how to interpret the data and provide. 

How do you say "here is a blob of trace data" I just got from some process, go 
find me a plug-in that can parse it. You might have to say "here is a blob of 
data" and it is for the "intel" trace data plug-in. How are we going to know 
which trace data to ask for? Is the packet we send to lldb-server going to 
reply to "qGetTraceData" with something that says the type of data is 
"intel-IEEE-version-123.3.1" and the data is "xxx"? Then we would find a 
plug-in in LLDB for that trace data that can parse it? So you will need to 
think about completely abstracting the whole notion of trace data into some 
sensible API that gets exposed via SBProcess. 

So yes, there are two approaches to take. Let me know which one is the way you 
want to go. But I really want to avoid the GDB remote protocol's async packets 
becoming the conduit for a boat load of information. 

Greg Clayton


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

Re: [lldb-dev] Making a new symbol provider

[Greg Clayton via lldb-dev]

> On Feb 11, 2016, at 3:41 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I want to make a new symbol provider to teach LLDB to understand microsoft 
> PDB files.  I've been looking over the various symbol APIs, and I have a few 
> questions.  
> 
> 1. Under what circumstances do I need a custom SymbolVendor?  The way pdb 
> works is that generally there is 1 file that contains all the debug info 
> needed for a single binary (so or executable).  Given a list of paths, we can 
> then determine if there is a matching PDB in one of those paths.  Is it 
> better to do this in the CalculateAbilities() function of the symbol file 
> plugin (by just returning 0 if we don't find a match) or do we need to do 
> something more complicated?

I would suggest make a SymbolVendorPDB that only enables itself if you are able 
to find the PDB files for your COFF file. So look at your COFF file, and I 
presume somewhere in there there is a pointer to one or more PDB files inside 
that file? CalculateAbililties is the correct place to see if a COFF file has 
pointers to PDB files and making sure those files exist before you say that you 
can provide any abilities.

> 
> 2. Why is there a function called ParseCompileUnitLanguage?  The CompileUnit 
> class already stores the language when ParseCompileUnit is called, and 
> ParseCompileUnitLanguage is implemented by just getting that value out.  What 
> is the poitn of this function?

If we are constructing CompileUnit instances with a valid language, we will 
never need to call the ParseCompileUnitLanguage function on 
SymbolVendor/SymbolFile, but it it is eLanguageTypeInvalid, we will lazily 
populate this later.

> 
> 3. There's a function called ParseCompileUnitDebugMacros.  Is this referring 
> to C / C++ macros?  Like #define FOO 7?  What is that used for?  I don't 
> believe info about preprocessor definitions are stored in PDB.  Is this going 
> to cause problems?

Nope, just don't implement. Hopefully there is a default implementation that 
does nothing. We should imply that by having a default implementation for this 
that there is nothing wrong with not filling it in.

> 
> 4. ParseCompileUnitSupportFiles.  What are "support files"?  Given a file 
> "foo.cpp" is this supposed to be header files etc?

This is largely mirroring how DWARF structures its data, but in general a 
compile unit might have files that it uses for line tables and decl file for 
things like variables. 

So any files in your line table should be in here. In DWARF the line tables use 
file indexes in their line tables to save space. Also any DWARF info that says 
"I am declared on line 12 of file 'Foo.c'" will use an index to refer to 
'Foo.c'. We use the compile unit support files for this:

case DW_AT_decl_file:   

decl.SetFile(sc.comp_unit->GetSupportFiles().GetFileSpecAtIndex(file_idx));
break;

The macro support you mention above also uses file indexes when referring to 
files.

So the support files should be a list of files that make sense to your PDB 
parser in case your PDB uses file indexes when referring to files. Since LLDB 
uses a partial parsing style of debug info, we only expand debug info into 
agnostic LLDB info lazily as the information is needed. All symbol files also 
get to pick their own identifiers for everything. For DWARF, we use the DIE 
offset as the identifier. So say you parse  DWARF that looks like:

0x000b: TAG_compile_unit [1] *
 AT_producer( "Apple LLVM version 7.0.0 (clang-700.1.72)" )
 AT_language( DW_LANG_C99 )
 AT_name( "main.c" )
 AT_stmt_list( 0x )
 AT_comp_dir( "/Volumes/work/gclayton/Documents/src/args" )
 AT_low_pc( 0x00010cf0 )
 AT_high_pc( 0x00010e9b )

0x002e: TAG_subprogram [2] *
 AT_low_pc( 0x00010cf0 )
 AT_high_pc( 0x00010e9b )
 AT_frame_base( rbp )
 AT_name( "main" )
 AT_decl_file( "main.c" )
 AT_decl_line( 9 )
 AT_prototyped( 0x01 )
 AT_type( {0x00c6} ( int ) )
 AT_external( 0x01 )

0x004d: TAG_formal_parameter [3]  
 AT_location( fbreg -1048 )
 AT_name( "argc" )
 AT_decl_file( "main.c" )
 AT_decl_line( 9 )
 AT_type( {0x00c6} ( int ) )

0x005c: TAG_formal_parameter [3]  
 AT_location( fbreg -1056 )
 AT_name( "argv" )
 AT_decl_file( "main.c" )
 AT_decl_line( 9 )
 AT_type( {0x00cd} ( const char** ) )

The ID of the compile unit is 0x000b since that is the DIE offset for the 
compile unit. If we ask the compile unit any questions through the 
lldb_private::CompileUnit, we can always extract the ID from the co

Re: [lldb-dev] target and host with different endianness

[Greg Clayton via lldb-dev]

> On Feb 11, 2016, at 7:55 AM, Philippe Lavoie via lldb-dev 
>  wrote:
> 
> 
> We have a big-endian target that we debug from LLDB running on Windows 
> through a custom process plugin and communication protocol.
> 
> The target's default byte order is set to eByteOrderBig in 
> 'g_core_definitions' in ArchSpec.cpp.
> 
> Most features work correctly (registers, variables, breakpoints, 
> disassembly), but expressions seem to ignore arch endianness:
> 
> For example:
> 
> (lldb) reg read pc
>   pc = 0x00400020  arithmetic.elf`main + 32 at main.c:12
> (lldb) expr -f hex -- $pc
> (unsigned int) $2 = 0x20004000
> (lldb)
> 
> Has this scenario (big-endian target and little-endian host) been tested/used 
> ?

Most things are currently little endian, so you will probably be one of the 
first. There shouldn't be much that needs to be fixed. All data we extract from 
memory is done via DataExtractor objects and they do have the notion of big and 
little endian, so there shouldn't be much more work than making sure the byte 
order gets correctly placed into the appropriate DataExtractor objects so that 
values are extracted correctly. I would guess the lldb_private::ValueObject's 
m_data member doesn't have the right byte order. The ValueObject should have a 
execution context (target, process, thread, frame, any of which should be 
valid) and the byte order can be retrieved from the Target's ArchSpec.

Let me know if you need any help,

Greg Clayton

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

Re: [lldb-dev] Prefered way to identify target device in tests?

[Greg Clayton via lldb-dev]

> On Feb 11, 2016, at 12:15 PM, Ted Woodward via lldb-dev 
>  wrote:
> 
> I’m working on getting the tests running with Hexagon, and have a question 
> about identifying the target architecture.
>  
> Hexagon LLVM doesn’t use a couple architectures like “x86_64” or “i386”, 
> instead we have many architectures, like “v4”, “v5”, “v55”, “v56”, v60”, so 
> using self.getArchitecture() can be problematic. I’ve got a list of Hexagon 
> architectures in a global supported_hexagon_versions in lldbtest.py. When I 
> need to check for Hexagon, should I do something like “self.getArchitecture 
> in supported_hexagon_versions”, or something like this:
>  
> self.runCmd("target list")
> if "arch=hexagon-*-*," in self.res.GetOutput():
>  
> ?
>  
> Ted

The architecture should be available from the test infrastructure. We have many 
tests that have @expectedFile(archs=re.compile("^mips")). So each test knows 
its architecture and this should be available in as a member variable of the 
TestBase object that everyone inherits from. Search for "mips" in all tests. I 
know some watchpoint tests are different on MIPS because they only have 1 
hardware watchpoint available, so they had to work around some issues in those 
tests. See how they did things and mimic that.

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

Re: [lldb-dev] Making a new symbol provider

[Greg Clayton via lldb-dev]

> On Feb 11, 2016, at 6:56 PM, Zachary Turner  wrote:
> 
> 
> 
> On Thu, Feb 11, 2016 at 5:35 PM Greg Clayton  wrote:
> 
> > On Feb 11, 2016, at 3:41 PM, Zachary Turner via lldb-dev 
> >  wrote:
> >
> > Hi,
> >
> > I want to make a new symbol provider to teach LLDB to understand microsoft 
> > PDB files.  I've been looking over the various symbol APIs, and I have a 
> > few questions.
> >
> > 1. Under what circumstances do I need a custom SymbolVendor?  The way pdb 
> > works is that generally there is 1 file that contains all the debug info 
> > needed for a single binary (so or executable).  Given a list of paths, we 
> > can then determine if there is a matching PDB in one of those paths.  Is it 
> > better to do this in the CalculateAbilities() function of the symbol file 
> > plugin (by just returning 0 if we don't find a match) or do we need to do 
> > something more complicated?
> 
> I would suggest make a SymbolVendorPDB that only enables itself if you are 
> able to find the PDB files for your COFF file. So look at your COFF file, and 
> I presume somewhere in there there is a pointer to one or more PDB files 
> inside that file? CalculateAbililties is the correct place to see if a COFF 
> file has pointers to PDB files and making sure those files exist before you 
> say that you can provide any abilities.
> Currently we use the operating system to query the PDBs.  This could change 
> in the future, but for now that's how we're doing it.  The operating system 
> does all the work of finding, matching, and loading the PDB for us, and it 
> does it all in one call.  So if we put this in the symbol vendor, there's no 
> way to say "is there a PDB" without also saying "actually load all the data 
> from the PDB" at the same time.  So I'm not sure if there's a solution to 
> this in there, because obviously I dont' want to load it twice.

Interesting. If you are on windows and you have a COFF file, you might just 
want to make a SymbolVendorCOFF. Does PDB info always and only get created for 
COFF files? 
> 
> One question I had about SymbolVendor, is that I looked at 
> SymbolVendorELF.cpp and it seems to boil down to this notion of "symbol file 
> representations".  All the logic in SymbolVendorELF exists just to add some 
> object file representations.  What is this supposed to represent?  I've got 
> an exe or something, what other "representation" is there other than the exe 
> itself?

In SymbolVendoerMacOSX, we have the executable and then the DWARF debug info in 
a stand alone dSYM bundle. So MacOSX you have a.out as the main ObjectFile 
(a.out) for a Module, but the symbols are in a different ObjectFile 
(a.out.dSYM). For ELF I believe there is information in the ELF file that 
_might_ point to a separate debug info file, but it also might just contain the 
DWARF in the executable. So for ELF you have 1 file (exec ELF that contains 
DWARF) or two files (exe ELF with no DWARF + debug info ELF with DWARF).

A symbol vendor's only job is to take an executable and and then use it plus 
any other files (its job is to locate these extra debug files) to make a single 
coherent view of the symbols for a lldb_private::Module. So the 
SymbolVendor::FindTypes(...) might look into the executable file and one or 
more other files to get the information. The information must be retrieved from 
one or more SymbolFile instances. A SymbolFile uses one ObjectFile to do its 
job. So there is a one to one mapping between SymbolFile and ObjectFile 
instances. The SymbolFile can use the same ObjectFile as the main executable if 
the data is in there. The SymbolVendor is the one that figures this out.

So some mappings might help show. The addresses before the object names are the 
address of the class in the LLDB address space. For a simple a.out ELF file 
that contains DWARF we would have:

0x1000: Module ("/tmp/a.out")
  m_obj_file = 0x2000
0x2000: ObjectFile ("/tmp/a.out")
0x3000: SymbolVendorELF
  m_sym_file = 0x4000
0x4000: SymbolFile
  m_obj_file = 0x2000


For a a.out ELF file that contains an external debug file "/var/debug/a.out"

0x1000: Module ("/tmp/a.out")
  m_obj_file = 0x2000
0x2000: ObjectFile ("/tmp/a.out")
0x2200: ObjectFile ("/var/debug/a.out")
0x3000: SymbolVendorELF
  m_sym_file = 0x4000
0x4000: SymbolFile
  m_obj_file = 0x2200

Same goes for MacOSX where we have "a.out" and "a.out.dSYM" except the 
SymbolVendorMacOSX is used since it knows how to locate the dSYM files.

If there are multiple ObjectFile objects that represent the debug info, they 
must share the same section list. So ObjectFiles and SymbolFiles work to make a 
single section list within lldb_private::Module that is used for all objects 
used to represent the symbol and debug info. That way the ObjectFile at 0x2000 
and 0x2200 above both use the same section for ".text", ".data", etc. If one 
ObjectFile has sections (like .debug_info for DWARF) where the other ObjectFile 
doesn't

Re: [lldb-dev] Why is storing SBTarget in a private field causing random crash?

[Greg Clayton via lldb-dev]

This is a clear bug in LLDB. If you have a repro case, please file a bug and 
attach the instructions on how to make this happen. Our API must be able to 
handle things like this.

SBTarget has a shared pointer to a lldb_private::Target. If you have a 
reference to a target, it should keep that target alive and it shouldn't crash 
later when it is actually freed. 

So please file a bug and we'll get it fixed. For a work around for now, yes, 
setting all SB references to None should help you work around the issue.

Greg

> On Feb 7, 2016, at 10:41 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I have been spending long time troubleshooting a race condition in our lldb 
> python test. I finally narrowed down to one code change that caused the race: 
> basically, whenever I store SBTarget in DebuggerTestCase's self.target field 
> lldb will randomly crash during destruction(see below). 
> 
> In the code, if I modify the two "self.target" to local variable "target" the 
> random crash will disappear. 
> 
> I am not a python expert. Why is holding SBTarget will cause the test to 
> random crash? Do I have to set every SBXXX fields to None before calling 
> SBDebugger.Destroy()?
> 
> 
> ==Crash Stack==
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
> 
> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes:   KERN_INVALID_ADDRESS at 0x0010
> 
> VM Regions Near 0x10:
> --> 
> __TEXT 00010d145000-00010d146000 [4K] r-x/rwx 
> SM=COW  
> /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   com.apple.LLDB.framework  0x0001101c037d 
> lldb_private::Listener::BroadcasterWillDestruct(lldb_private::Broadcaster*) + 
> 95
> 1   com.apple.LLDB.framework  0x0001101a0da2 
> lldb_private::Broadcaster::Clear() + 50
> 2   com.apple.LLDB.framework  0x0001101a0ced 
> lldb_private::Broadcaster::~Broadcaster() + 75
> 3   com.apple.LLDB.framework  0x0001103d6879 
> lldb_private::Target::~Target() + 741
> 4   com.apple.LLDB.framework  0x0001103d6c20 
> lldb_private::Target::~Target() + 14
> 5   libc++.1.dylib0x7fff896448a6 
> std::__1::__shared_weak_count::__release_shared() + 44
> 6   com.apple.LLDB.framework  0x00010e560664 
> _wrap_delete_SBTarget(_object*, _object*) + 123
> 7   org.python.python 0x00010d15a50a PyObject_Call + 99
> 
> 
> ==Code==
> from find_lldb import lldb
> from simplest_event_thread import LLDBListenerThread
> import unittest
> import threading
> 
> running_signal = threading.Event()
> stopped_signal = threading.Event()
> 
> def launch_debugging(debugger, stop_at_entry):
> error = lldb.SBError()
> listener = lldb.SBListener('Chrome Dev Tools Listener')
> target = debugger.GetSelectedTarget()
> process = target.Launch (listener,
> None,  # argv
> None,  # envp
> None,  # stdin_path
> None,  # stdout_path
> None,  # stderr_path
> None,  # working directory
> 0, # launch flags
> stop_at_entry,  # Stop at entry
> error) # error
> print 'Launch result: %s' % str(error)
> 
> event_thread = LLDBListenerThread(debugger, running_signal, 
> stopped_signal)
> event_thread.start()
> 
> running_signal.set()
> return event_thread
> 
> class DebuggerTestCase:
> 
> def wait_for_process_stop(self):
> running_signal.wait()
> running_signal.clear()
> stopped_signal.wait()
> stopped_signal.clear()
> 
> def test_breakpoint_at_line(self):
> debugger = lldb.SBDebugger.Create()
> debugger.SetAsync(True)
> executable_path = 
> '~/Personal/compiler/CompilerConstruction/code/compiler'
> self.target = debugger.CreateTargetWithFileAndArch(executable_path, 
> lldb.LLDB_ARCH_DEFAULT)
> 
> event_thread = launch_debugging(debugger, stop_at_entry=True)
> 
> process = debugger.GetSelectedTarget().process
> self.wait_for_process_stop() # wait for entry breakpoint.
> self.target.BreakpointCreateByName('main')
> process.Continue()
> self.wait_for_process_stop() # wait for main breakpoint.
> 
> event_thread.should_quit = True
> event_thread.join()
> lldb.SBDebugger.Destroy(debugger)
> 
> if __name__ == '__main__':
> test = DebuggerTestCase()
> for i in range(20):
> test.test_breakpoint_at_line()
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/lis

Re: [lldb-dev] Race condition crashes during launching LLDB

[Greg Clayton via lldb-dev]

If you are going to set async to true, then you must consume the events by 
waiting for events. See the following example:

svn cat 
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py

So you can rewrite your wait_for_process_stop to use the debugger to fetch the 
events and do things correctly:

def wait_for_process_stop(debugger):
  event_timeout_in_seconds = 10
  listener = debugger.GetListener()
  event = lldb.SBEvent()
  stopped = False
  while not stopped:
if listener.WaitForEvent (event_timeout_in_seconds, event):
  if lldb.SBProcess.EventIsProcessEvent(event):
state = lldb.SBProcess.GetStateFromEvent (event)
if state == lldb.eStateStopped:
  // Watch for something that stopped and restarted automatically
  if SBProcess::GetRestartedFromEvent(event) == False:
stopped = True


The other option is to do it to set Async to False and then your target.Launch 
won't return until the process is stopped. Also if you do "process.Continue()" 
it won't return until the process is stopped. But you lose your ability to stop 
the process if things go wrong...

Greg

> On Feb 4, 2016, at 9:09 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> After adding some logging I figured out that the race condition is caused by 
> process.Continue() did not guarantee process has been really resumed yet in 
> async mode, so the second wait_for_process_stop() is skipped immediately to 
> kill listener thread and destroying debugger. I know I have a race condition 
> bug here because of polling for process state, but why is lldb crashing when 
> listener thread has exited and SBDebugger.Destroy() is called? What is the 
> situation that SBDebugger.Destroy() can be called safely?
> 
> ==do_test==
> Launch result: success
>  Listening Thread ID: 4660334592
> WaitForEvent...
> Target event: ModulesLoaded
> WaitForEvent...
> Process event: StateChanged, Stopped
> Stop reason: 5
> WaitForEvent...
> Breakpoint event: [Added] SBBreakpoint: id = 1, name = 'main', locations = 1
> WaitForEvent...
> [main] killing listener thread
>  Process event: StateChanged, Running
> Stop reason: 0
>  Exiting listener thread
> [main] destroy debugger
> Segmentation fault: 11
> 
> On Thu, Feb 4, 2016 at 8:22 PM, Jeffrey Tan  wrote:
> Sorry, I have actually tried to exit the event listening thread before 
> debugger destroy, but still go the crash randomly(1 out of 5 runs). Here is 
> the code:
> 
> 
> ==Main Thread==
> def wait_for_process_stop(process):
> while not process.is_stopped:
> time.sleep(0.1)
> 
> def launch_debugging(debugger, stop_at_entry):
> error = lldb.SBError()
> listener = lldb.SBListener('Chrome Dev Tools Listener')
> target = debugger.GetSelectedTarget()
> process = target.Launch (listener,
> None,  # argv
> None,  # envp
> None,  # stdin_path
> None,  # stdout_path
> None,  # stderr_path
> None,  # working directory
> 0, # launch flags
> stop_at_entry,  # Stop at entry
> error) # error
> print 'Launch result: %s' % str(error)
> listener_thread = LLDBListenerThread(debugger)
> listener_thread.start()
> return listener_thread
> 
> def do_test():
> debugger = lldb.SBDebugger.Create()
> debugger.SetAsync(True)
> executable_path = '~/Personal/compiler/CompilerConstruction/code/compiler'
> target = debugger.CreateTargetWithFileAndArch(executable_path, 
> lldb.LLDB_ARCH_DEFAULT)
> 
> listener_thread = launch_debugging(debugger, stop_at_entry=True)
> process = debugger.GetSelectedTarget().process
> 
> wait_for_process_stop(process) # wait for entry breakpoint.
> target.BreakpointCreateByName('main')
> process.Continue()
> wait_for_process_stop(process) # wait for main breakpoint.
> 
> listener_thread.should_quit = True
> listener_thread.join()
> 
> lldb.SBDebugger.Destroy(debugger)
> 
> def main():
> do_test()
> do_test()
> 
> ==Listening Thread==
> class LLDBListenerThread(Thread):
> should_quit = False
> 
> def __init__(self, debugger):
>   Thread.__init__(self)
>   process = debugger.GetSelectedTarget().process
>   self.listener = debugger.GetListener()
>   self._add_listener_to_process(process)
>   self._add_listener_to_target(process.target)
> 
>def _add_listener_to_target(self, target):
> # Listen for breakpoint/watchpoint events 
> (Added/Removed/Disabled/etc).
> broadcaster = target.GetBroadcaster()
> mask = lldb.SBTarget.eBroadcastBitBreakpointChanged | 
> lldb.SBTarget.eBroadcastBitWatchpointChanged | 
> lldb.SBTarget.eBroadcastBitModulesLoaded
> broadcaster.AddListener(self.listener, mask)
> 
> def _add_

Re: [lldb-dev] Race condition crashes during launching LLDB

[Greg Clayton via lldb-dev]

The main problem you are running into is in async mode when you say "launch" or 
"continue", those calls will return immediately and you must consume the events 
to make sure it is safe to do things. If your process is stopped, then until 
your actually resume your process with process.Continue() or any 
thread.StepXXX() calls, your process will stay stopped. But when you ask to 
make it run, you must consume events to know what the process is actually 
doing...


> On Feb 12, 2016, at 10:02 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> If you are going to set async to true, then you must consume the events by 
> waiting for events. See the following example:
> 
> svn cat 
> http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
> 
> So you can rewrite your wait_for_process_stop to use the debugger to fetch 
> the events and do things correctly:
> 
> def wait_for_process_stop(debugger):
>  event_timeout_in_seconds = 10
>  listener = debugger.GetListener()
>  event = lldb.SBEvent()
>  stopped = False
>  while not stopped:
>if listener.WaitForEvent (event_timeout_in_seconds, event):
>  if lldb.SBProcess.EventIsProcessEvent(event):
>state = lldb.SBProcess.GetStateFromEvent (event)
>if state == lldb.eStateStopped:
>  // Watch for something that stopped and restarted automatically
>  if SBProcess::GetRestartedFromEvent(event) == False:
>stopped = True
> 
> 
> The other option is to do it to set Async to False and then your 
> target.Launch won't return until the process is stopped. Also if you do 
> "process.Continue()" it won't return until the process is stopped. But you 
> lose your ability to stop the process if things go wrong...
> 
> Greg
> 
>> On Feb 4, 2016, at 9:09 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> After adding some logging I figured out that the race condition is caused by 
>> process.Continue() did not guarantee process has been really resumed yet in 
>> async mode, so the second wait_for_process_stop() is skipped immediately to 
>> kill listener thread and destroying debugger. I know I have a race condition 
>> bug here because of polling for process state, but why is lldb crashing when 
>> listener thread has exited and SBDebugger.Destroy() is called? What is the 
>> situation that SBDebugger.Destroy() can be called safely?
>> 
>> ==do_test==
>> Launch result: success
>>  Listening Thread ID: 4660334592
>> WaitForEvent...
>> Target event: ModulesLoaded
>> WaitForEvent...
>> Process event: StateChanged, Stopped
>> Stop reason: 5
>> WaitForEvent...
>> Breakpoint event: [Added] SBBreakpoint: id = 1, name = 'main', locations = 1
>> WaitForEvent...
>> [main] killing listener thread
>> Process event: StateChanged, Running
>> Stop reason: 0
>>  Exiting listener thread
>> [main] destroy debugger
>> Segmentation fault: 11
>> 
>> On Thu, Feb 4, 2016 at 8:22 PM, Jeffrey Tan  wrote:
>> Sorry, I have actually tried to exit the event listening thread before 
>> debugger destroy, but still go the crash randomly(1 out of 5 runs). Here is 
>> the code:
>> 
>> 
>> ==Main Thread==
>> def wait_for_process_stop(process):
>>while not process.is_stopped:
>>time.sleep(0.1)
>> 
>> def launch_debugging(debugger, stop_at_entry):
>>error = lldb.SBError()
>>listener = lldb.SBListener('Chrome Dev Tools Listener')
>>target = debugger.GetSelectedTarget()
>>process = target.Launch (listener,
>>None,  # argv
>>None,  # envp
>>None,  # stdin_path
>>None,  # stdout_path
>>None,  # stderr_path
>>None,  # working directory
>>0, # launch flags
>>stop_at_entry,  # Stop at entry
>>error) # error
>>print 'Launch result: %s' % str(error)
>>listener_thread = LLDBListenerThread(debugger)
>>listener_thread.start()
>>return listener_thread
>> 
>> def do_test():
>>debugger = lldb.SBDebugger.Create()
>>debugger.SetAsync(True)
>>executable_path = '~/Personal/compiler/CompilerConstruction/code/compiler'
>>target = debugger.CreateTargetWithFileAndArch(executable_path, 
>> lldb.LLDB_ARCH_DEFAULT)
>> 
>>listener_thread = launch_debugging(debugger, stop_a

Re: [lldb-dev] problem with quoted strings in setting target.run-args

[Greg Clayton via lldb-dev]

> On Feb 18, 2016, at 4:16 PM, Ted Woodward via lldb-dev 
>  wrote:
> 
> Quoted strings in target.run-args aren’t handled correctly.
>  
> (lldb) settings set target.run-args "foo bar"
> (lldb) settings show target.run-args
> target.run-args (array of strings) =
>   [0]: "foo bar"
>  
> This looks correct, but the Args in the ProcessLaunchInfo passed to the 
> Platform doesn’t have m_args_quote_char set, so if the Args is later pulled 
> out with GetQuotedCommandString() it won’t get “foo bar”, but will instead 
> get foo and bar unquoted. This is masked when talking to debugserver or 
> lldb_server because run-args are sent to the server using an RSP packet, but 
> on systems like Windows or the Hexagon Simulator, where run-args are on the 
> command line, you get 2 args, foo and bar, instead of 1 arg “foo bar”.
>  
> The first problem is in OptionValueArray::SetArgs(), in the 
> eVarSetOperationAppend case. It calls Args::GetArgumentAtIndex(), which 
> doesn’t return a quoted argument. I added a function 
> GetQuotedArgumentAtIndex() and called that, which revealed the second 
> problem. The string is passed into 
> OptionValue::CreateValueFromCStringForTypeMask(), which calls 
> OptionValueString::SetValueFromString(). In that function it explicitly 
> strips quotes. Changing it to not strip quotes leads to the third problem – 
> when TargetProperties::RunArgsValueChangedCallback() pulls the data from the 
> OptionValueArray to make a new Args, it calls OptionValueArray::GetArgs(), 
> which doesn’t handle quoting like the Args ctor does.
>  
> I think changing the OptionValue classes to handle quoting could lead to 
> problems with other use cases. So that leaves me with the option of going 
> through the Args before launch and adding quotes around anything with spaces, 
> which seems hackish. Any thoughts on how to solve this issue?

Any changes that are made need to know a few things:
1 - Many things that take arguments don't need the quotes for the arguments, 
the quotes are there to help us split arguments that contain things that must 
be quoted. Things like exec and posix_spawn take a "const char **" NULL 
terminate array of C strings. And the quotes are not needed, nor are they 
wanted and if you add them, they will hose things up.
2 - Anyone launching via an API that launches through a shell will need to 
quote correctly for your given shell or launch mechanism. There are no 
guarantees that the original quotes (ours mimic bash and other shell quoting) 
will be what you will want/need when you launch (launch in command.exe in 
windows).

What OptionValueArgs should contain is a valid list of strings that has been 
broken up into args. If that is currently true, I don't see a bug here. I am 
fine with you adding a method to OptionValueArgs that is something like 
"GetQuotedCommandString(...)" that would add the quotes as needed, but again, 
this might be specific to the shell. I know what bash and tcsh expect, but what 
does windows expect? Can you use single quoted strings if your arguments 
contain double quotes? Can you use double quotes if your argument has single 
quotes? Can you escape the quote characters with a '\' character? That seems 
like a lot of arguments to pass to the GetQuotedCommandString() function, but 
you will need to make it this way if so...

But the _only_ client of OptionValueArgs is the "run-args" so the other option 
would be to switch OptionValueArgs over to use lldb_private::Args instead of 
inheriting from OptionValueArray. If you do this, you will need to implement 
many of the OptionValue virtual functions like:

virtual void
DumpValue (const ExecutionContext *exe_ctx, Stream &strm, uint32_t 
dump_mask) = 0;

virtual Error
SetValueFromString (llvm::StringRef value, VarSetOperationType op = 
eVarSetOperationAssign);

virtual bool
Clear () = 0;

virtual lldb::OptionValueSP
DeepCopy () const = 0;

Then you would have something that still has the strings split up and yet still 
knows what the original quoting was like since you would store your arguments 
in a lldb_private::Args array that would be a member variable of 
OptionValueArgs.



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

Re: [lldb-dev] lldb-mi and shared library path

[Greg Clayton via lldb-dev]

> On Feb 4, 2016, at 1:51 PM, Ted Woodward via lldb-dev 
>  wrote:
> 
> I’d expect “-gdb-set solib-search-path” to call “target modules search-paths 
> add”, and it does, but only when the –target-remote command is issued. It 
> also doesn’t handle the multiple path case, :…
>  
> I think it should:
>  
> 1)  Set the search path immediately when called, if the target is 
> connected
> 2)  Set the search path on run/attach
> 3)  Handle multiple paths
>  
> Any thoughts on this?
>  

Here are some thoughts that say kind of how we are doing things, and after 
reading this it might adjust your request:

In LLDB the approach we have taken is that when you are going to remotely debug 
something, your Platform is responsible for finding any remote file paths might 
not match the local file paths. 

For Apple with iOS, we have one or more root directories available for us to 
grab system files from (everything from /usr/lib/* /System/Library/Frameworks, 
etc). Only the executables you just built tend to exist outside of the system 
roots, so as long as your provide those to LLDB prior to running ("target 
create /path/to/locally/built/cross/executable"), we will be able to match up 
the binaries using their UUID even if the remote path is 
"/users/admin/executable". There are also ways to say "I built 
/path/to/locally/built/cross/executable and 
/path/to/locally/built/cross/libfoo.so and 
/path/to/locally/built/cross/libbar.so", now attach to a remote binary to debug 
these things. The extra .so files can be added to your target with "target 
module add /path/to/locally/built/cross/libfoo.so" and "target module add 
/path/to/locally/built/cross/libbar.so" and then we will be able to find these 
files when they are needed.

So the main questions becomes: if you modify your platform to do the right 
thing, do you need any of the changes you are requesting ("-gdb-set 
solib-search-path" or "target modules search-paths add")?

This is how things were done back with GDB, but in LLDB we are trying to make 
our Platform subclasses do a lot of this hard work for us. Your Platform could 
check with a build server and download and cache any binaries it needed. It 
could look through a set of directories or other commonly used areas for these 
files, it really depends on how your SDK/PDK is setup and how your builds tend 
to happen. If you have an IDE that is creating binaries, it typically knows 
about all of the build products you might be trying to debug, and it can often 
supply the build products to LLDB in case it needs them.

Let me know.

Greg Clayton


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

Re: [lldb-dev] Sending input to the process being debugged

[Greg Clayton via lldb-dev]

You have to consume the events from the debugger's listener (unless you specify 
a different listener in your SBLaunchInfo or SBAttachInfo). 

We have python code that can show you how to consume events:

svn cat 
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py

So even though your process might be stopped, until you consume the stop event, 
the process will claim it is running or launching.

The process broadcasts process event state changes (changing from running to 
stopped, or stopped to running). 

If you have more detailed questions, please let me know.

Greg Clayton

> On Feb 3, 2016, at 2:03 PM, John Lindal via lldb-dev 
>  wrote:
> 
> When I use SBDebugger::SetAsync(true), the process is not stopped at scanf, 
> so it does not wait for input.  The process does stop and wait for input when 
> SetAsync(false).  Unfortunately, when building a GUI on top of the C++ API, I 
> have to SetAsync(true).
> 
> Is there some way to resolve this?
> 
> Thanks,
> 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] Module Cache improvements - RFC

[Greg Clayton via lldb-dev]

> On Jan 28, 2016, at 4:21 AM, Pavel Labath  wrote:
> 
> Hello all,
> 
> we are running into limitations of the current module download/caching
> system. A simple android application can link to about 46 megabytes
> worth of modules, and downloading that with our current transfer rates
> takes about 25 seconds. Much of the data we download this way is never
> actually accessed, and yet we download everything immediately upon
> starting the debug session, which makes the first session extremely
> laggy.
> 
> We could speed up a lot by only downloading the portions of the module
> that we really need (in my case this turns out to be about 8
> megabytes). Also, further speedups could be made by increasing the
> throughput of the gdb-remote protocol used for downloading these files
> by using pipelining.
> 
> I made a proof-of-concept hack  of these things, put it into lldb and
> I was able to get the time for the startup-attach-detach-exit cycle
> down to 5.4 seconds (for comparison, the current time for the cycle is
> about 3.6 seconds with a hot module cache, and 28(!) seconds with an
> empty cache).
> 
> Now, I would like to properly implement these things in lldb properly,
> so this is a request for comments on my plan. What I would like to do
> is:
> - Replace ModuleCache with a SectionCache (actually, more like a cache
> of arbitrary file chunks). When a the cache gets a request for a file
> and the file is not in the cache already, it returns a special kind of
> a Module, whose fragments will be downloaded as we are trying to
> access them. These fragments will be cached on disk, so that
> subsequent requests for the file do not need to re-download them. We
> can also have the option to short-circuit this logic and download the
> whole file immediately (e.g., when the file is small, or we have a
> super-fast way of obtaining the whole file via rsync, etc...)
> - Add pipelining support to GDBRemoteCommunicationClient for
> communicating with the platform. This actually does not require any
> changes to the wire protocol. The only change is in adding the ability
> to send an additional request to the server while waiting for the
> response to the previous one. Since the protocol is request-response
> based and we are communication over a reliable transport stream, each
> response can be correctly matched to a request even though we have
> multiple packets in flight. Any packets which need to maintain more
> complex state (like downloading a single entity using continuation
> packets) can still lock the stream to get exclusive access, but I am
> not sure if we actually even have any such packets in the platform
> flavour of the protocol.
> - Paralelize downloading of multiple files in parallel, utilizing
> request pipelining. Currently we get the biggest delay when first
> attaching to a process (we download file headers and some basic
> informative sections) and when we try to set the first symbol-level
> breakpoint (we download symbol tables and string sections). Both of
> these actions operate on all modules in bulk, which makes them easy
> paralelization targets. This will provide a big speed boost, as we
> will be eliminating communication latency. Furthermore, in case of
> lots of files, we will be overlapping file download  (io) with parsing
> (cpu), for an even bigger boost.
> 
> What do you think?
> 

Feel free to implement this in PlatformAndroid and allow others to opt into 
this. I won't want this by default in any of the Apple platforms in MachO we 
have our entire image mapped into memory and we have other tricks for getting 
the information quicker.

So I would leave the module cache there and not change it, but feel free to add 
the section cache as needed. Maybe if this goes really well and it can be 
arbitrarily used on any files types (MachO, ELF, COFF, etc) and it just works 
seamlessly, we can expand who uses it. 

In Xcode we take the time the first time we connect to a device we haven't seen 
to download all of the system libraries. Why is the 28 seconds considered 
prohibitive for the first time you connect. The data stays cached even after 
you quit and restart LLDB or your IDE right?

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

Re: [lldb-dev] lldb-mi and shared library path

[Greg Clayton via lldb-dev]

Ok, sounds like you first need to see if "-gdb-set solib-search-path" is hooked 
up to "target modules search-paths add". If not, hook it up. Then we probably 
need to add a function to Platform.cpp that can use a target's module search 
paths to help find an executable. This can probably be a virtual function in 
Platform.h/cpp that will work for all platforms. So then each platform would 
try to locate the binary on its own using Platform::ResolveExecutable(...) or 
Platform::ResolveRemotePath(...) we should use the target's module search paths 
as places to look. This means that Platform::ResolveRemotePath(...) might need 
to take a Target list Platform::ResolveExecutable(...) already does. Does that 
make sense?

Greg

> On Feb 22, 2016, at 5:07 PM, Ted Woodward  wrote:
> 
> The Hexagon SDK taking to hardware is very bare bones. The OS is sitting on 
> the phone and is loaded to the Hexagon by Android. The debugger opens the OS 
> elf file, the user tells it where the shared libraries are, and lldb does the 
> usual stop-at-the-rendezvous function negotiation to get info when shared 
> libraries are loaded. Each example application is its own shared library, and 
> each is built in a different directory. I don't think I can have the Platform 
> do the hard work, because the shared libraries could be anywhere.
> 
> It works fine when we run lldb; it doesn't when our Eclipse guy runs lldb-mi. 
> I'm having fun looking at lots of logs!
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com] 
> Sent: Monday, February 22, 2016 6:24 PM
> To: Ted Woodward
> Cc: LLDB
> Subject: Re: [lldb-dev] lldb-mi and shared library path
> 
> 
>> On Feb 4, 2016, at 1:51 PM, Ted Woodward via lldb-dev 
>>  wrote:
>> 
>> I’d expect “-gdb-set solib-search-path” to call “target modules search-paths 
>> add”, and it does, but only when the –target-remote command is issued. It 
>> also doesn’t handle the multiple path case, :…
>> 
>> I think it should:
>> 
>> 1)  Set the search path immediately when called, if the target is 
>> connected
>> 2)  Set the search path on run/attach
>> 3)  Handle multiple paths
>> 
>> Any thoughts on this?
>> 
> 
> Here are some thoughts that say kind of how we are doing things, and after 
> reading this it might adjust your request:
> 
> In LLDB the approach we have taken is that when you are going to remotely 
> debug something, your Platform is responsible for finding any remote file 
> paths might not match the local file paths. 
> 
> For Apple with iOS, we have one or more root directories available for us to 
> grab system files from (everything from /usr/lib/* 
> /System/Library/Frameworks, etc). Only the executables you just built tend to 
> exist outside of the system roots, so as long as your provide those to LLDB 
> prior to running ("target create /path/to/locally/built/cross/executable"), 
> we will be able to match up the binaries using their UUID even if the remote 
> path is "/users/admin/executable". There are also ways to say "I built 
> /path/to/locally/built/cross/executable and 
> /path/to/locally/built/cross/libfoo.so and 
> /path/to/locally/built/cross/libbar.so", now attach to a remote binary to 
> debug these things. The extra .so files can be added to your target with 
> "target module add /path/to/locally/built/cross/libfoo.so" and "target module 
> add /path/to/locally/built/cross/libbar.so" and then we will be able to find 
> these files when they are needed.
> 
> So the main questions becomes: if you modify your platform to do the right 
> thing, do you need any of the changes you are requesting ("-gdb-set 
> solib-search-path" or "target modules search-paths add")?
> 
> This is how things were done back with GDB, but in LLDB we are trying to make 
> our Platform subclasses do a lot of this hard work for us. Your Platform 
> could check with a build server and download and cache any binaries it 
> needed. It could look through a set of directories or other commonly used 
> areas for these files, it really depends on how your SDK/PDK is setup and how 
> your builds tend to happen. If you have an IDE that is creating binaries, it 
> typically knows about all of the build products you might be trying to debug, 
> and it can often supply the build products to LLDB in case it needs them.
> 
> Let me know.
> 
> Greg Clayton
> 
> 
> 

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

Re: [lldb-dev] Module Cache improvements - RFC

[Greg Clayton via lldb-dev]

I believe this is already done.

I am guessing the main issue is this happens on the first time you debug to a 
device you and up with a 30 second delay with no feedback as to what is going 
on. So you say "launch" and then 35 seconds later you hit your breakpoint at 
main. In Xcode we solve this by downloading all of the files when we attach to 
a device for the first time and we show progress as we download all shared 
libraries. Sounds like it would be good for Android Studio to do the same thing?

Greg
> On Feb 22, 2016, at 5:27 PM, Zachary Turner  wrote:
> 
> Can't you just cache the modules locally on the disk, so that you only take 
> that 26 second hit the first time you try to download that module, and then 
> it indexes it by some sort of hash.  Then instead of just downloading it, you 
> check the local cache first and only download if it's not there.
> 
> If you already do all this, then disregard.
> 
> On Mon, Feb 22, 2016 at 4:39 PM Greg Clayton via lldb-dev 
>  wrote:
> 
> > On Jan 28, 2016, at 4:21 AM, Pavel Labath  wrote:
> >
> > Hello all,
> >
> > we are running into limitations of the current module download/caching
> > system. A simple android application can link to about 46 megabytes
> > worth of modules, and downloading that with our current transfer rates
> > takes about 25 seconds. Much of the data we download this way is never
> > actually accessed, and yet we download everything immediately upon
> > starting the debug session, which makes the first session extremely
> > laggy.
> >
> > We could speed up a lot by only downloading the portions of the module
> > that we really need (in my case this turns out to be about 8
> > megabytes). Also, further speedups could be made by increasing the
> > throughput of the gdb-remote protocol used for downloading these files
> > by using pipelining.
> >
> > I made a proof-of-concept hack  of these things, put it into lldb and
> > I was able to get the time for the startup-attach-detach-exit cycle
> > down to 5.4 seconds (for comparison, the current time for the cycle is
> > about 3.6 seconds with a hot module cache, and 28(!) seconds with an
> > empty cache).
> >
> > Now, I would like to properly implement these things in lldb properly,
> > so this is a request for comments on my plan. What I would like to do
> > is:
> > - Replace ModuleCache with a SectionCache (actually, more like a cache
> > of arbitrary file chunks). When a the cache gets a request for a file
> > and the file is not in the cache already, it returns a special kind of
> > a Module, whose fragments will be downloaded as we are trying to
> > access them. These fragments will be cached on disk, so that
> > subsequent requests for the file do not need to re-download them. We
> > can also have the option to short-circuit this logic and download the
> > whole file immediately (e.g., when the file is small, or we have a
> > super-fast way of obtaining the whole file via rsync, etc...)
> > - Add pipelining support to GDBRemoteCommunicationClient for
> > communicating with the platform. This actually does not require any
> > changes to the wire protocol. The only change is in adding the ability
> > to send an additional request to the server while waiting for the
> > response to the previous one. Since the protocol is request-response
> > based and we are communication over a reliable transport stream, each
> > response can be correctly matched to a request even though we have
> > multiple packets in flight. Any packets which need to maintain more
> > complex state (like downloading a single entity using continuation
> > packets) can still lock the stream to get exclusive access, but I am
> > not sure if we actually even have any such packets in the platform
> > flavour of the protocol.
> > - Paralelize downloading of multiple files in parallel, utilizing
> > request pipelining. Currently we get the biggest delay when first
> > attaching to a process (we download file headers and some basic
> > informative sections) and when we try to set the first symbol-level
> > breakpoint (we download symbol tables and string sections). Both of
> > these actions operate on all modules in bulk, which makes them easy
> > paralelization targets. This will provide a big speed boost, as we
> > will be eliminating communication latency. Furthermore, in case of
> > lots of files, we will be overlapping file download  (io) with parsing
> > (cpu), for an even bigger boost.
> >
> > What do you think?
> >
> 
> Feel free to implement this in PlatformAndroid and allow others to opt in

Re: [lldb-dev] Module Cache improvements - RFC

[Greg Clayton via lldb-dev]

> On Feb 23, 2016, at 10:31 AM, Nico Weber  wrote:
> 
> On Tue, Feb 23, 2016 at 1:21 PM, Tamas Berghammer via lldb-dev 
>  wrote:
> Yes we already have a disk cache on the host. I agree with you that waiting 
> 30s at the first startup shouldn't be an issue in general (Pavel isn't 
> sharing my opinion). The only catch is that in case of iOS there are only a 
> few different builds released so if you downloaded the modules once then I 
> think you won't have to download them the next time when you try to use a 
> different device. In case of Android we have to download the symbols from 
> each device you are using and at that point 30s might be an issue (I still 
> don't think it is).
> 
> With my app developer hat on, if some program makes me wait 30s for something 
> then I won't like that program.

I agree, but if the first time you hook your phone up Android Studio pops up a 
dialog box saying "This is the first time you have connected this device, hold 
on while I cache the shared libraries for this device..." then it wouldn't be 
too bad. It is primarily the fact that the 30 seconds is happening without 
feedback during first launch or attach. Also, you can probably use something 
faster than the lldb-platform to download all of the files. In Xcode, we 
download all symbols into the users home directory in a known location:

~/Library/Developer/Xcode/iOS DeviceSupport

This folder contains the exact OS version and a build number:

(lldb) platform select remote-ios 
  Platform: remote-ios
 Connected: no
 SDK Roots: [ 0] "~/Library/Developer/Xcode/iOS DeviceSupport/9.0 (W)"
 SDK Roots: [ 1] "~/Library/Developer/Xcode/iOS DeviceSupport/9.1 (X)"
 SDK Roots: [ 2] "~/Library/Developer/Xcode/iOS DeviceSupport/9.2 (Y)"

Where W, X, Y are build numbers. We know we can look in these 
folders for any files that are from the device. They get populated and these 
SDK directories get searched by LLDB's PlatformRemoteiOS so they get found (we 
don't use the file cache that the PlatformAndroid currently uses).

So with a little work, I would add some functionality to your Android Studio, 
have something that knows how to copy files from device as quickly as possible 
(using lldb-platform is slwww and that is the way it is currently done I 
believe) into some such directory, all while showing a progress dialog to the 
user on first device connect, and then debugging will always be quick. And you 
can probably make it quicker than 30 seconds.

Greg Clayton


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

Re: [lldb-dev] How to use the C++ API? No useful documentation?

[Greg Clayton via lldb-dev]

I need to spend some time writing this up, but until then here is some info.

We created a python script that uses the LLDB public API to grab async events 
so people can see how to do things:

svn cat 
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py

If you look in here you will see the correct way to do things.

I will answer you questions inlined into your email below and then add some 
extra tips at the end:

> On Feb 20, 2016, at 3:04 PM, Paul Peet via lldb-dev  
> wrote:
> 
> Hello,
> 
> I am currently working on an IDE for C++ and I would like to integrate lldb 
> as a debugger using the C++ API but it has been difficult for me to 
> understand the architecture because there is no documentation available 
> (except doxygen which isn't helpful at all).
> I am at the point understanding the Event system? How are Events created?

You need to be able to listen for events from your debug session. In order to 
do this, SBBroadcaster objects can broadcast events as SBEvent objects. You 
need to listen for events using a SBListener. Each SBBroadcaster will broadcast 
events where each different kind of event is represented by one bit in a 32 bit 
uint32_t. 

> How can I use SBListener and SBBroadcaster? (What's the function of 
> SBBroadvaster).

Yes you can. You might want to use a SBBroadcaster to send events to your main 
event loop in the debugger:

using namespace lldb;
SBBroadcaster gui_event_broadcaster("gui-events");

// Define the event bits we will use for gui_event_broadcaster
enum
{
  eGUIEventBitLaunch   = (1u << 0),
  eGUIEventBitKill = (1u << 1),
  eGUIEventBitStepOver = (1u << 2),
  eGUIEventBitStepOut  = (1u << 3),
  eGUIEventBitStepInto = (1u << 4),
  eGUIEventBitContinue = (1u << 5),
  eGUIEventBitHalt = (1u << 6),
  eGUIEventBitQuit = (1u << 7),
  eGUIEventAll = UINT32_MAX
};

SBListener run_loop_listener("run-loop-listener");
// Listen for any event from gui_event_broadcaster by listening to all event 
bits
run_loop_listener.StartListeningForEvents(gui_event_broadcaster, eGUIEventAll);

You can then run an event loop on a thread:

void
RunLoop()
{
  SBEvent event;
  bool done = false
  while (!done)
  {
if (listener.WaitForEvent(UINT32_MAX, event))
{
  const uint32_t event_type = event.GetType();
  if (event.BroadcasterMatchesRef(gui_event_broadcaster))
  {
switch (event_type)
{
case eGUIEventBitLaunch:
case eGUIEventBitKill:
case eGUIEventBitQuit:
}
  }
}
  }
}


Then on another thread, you can broadcast events. Lets say the user clicked the 
"kill" button in your IDE, you could broadcast an event:

gui_event_broadcaster.BroadcastEventByType(eGUIEventBitKill);

Then the event loop would receive the event, as long as it is listening for 
these events. So you can use SBBroadcaster and SBListener yourself, but many 
objects (like SBTarget, SBProcess and SBThread) are already broadcasters and 
will broadcast events to you and you can sign up to listen to the events they 
send out. I would recommend starting with SBProcess, and you will see how to 
listen to events by looking at the python code.


> 
> My current code looks something like this:
> 
> SBListener listener;
> SBProcess process = target.Launch(listener, args, env, nullptr, nullptr,
>   nullptr, "/home/cynecx/dev/helloWorld",
>   0, true, error);
> 
> process.Continue();
> 
> StateType state = process.GetState(); // is stopped
> 
> SBEvent event;
> 
> while(true) {
>   if(listener.WaitForEvent(0x, event)) {
> // This branch is never hit
> SBStream stream;
> event.GetDescription(stream);
> std::cout << stream.GetData() << std::endl;
>   } else {
> break;
>   }
> }
> 
> It would help developers (IDE) a lot if there might be some 
> tutorials/documentation on how to use the API.

I agree. We will try to get this up on the web at some point in the near future.

Some more pointers:

- When launching, use a SBLaunchInfo:

const char *argv[] = { "/bin/ls", "-l", "-A", "-F", nullptr };
SBLaunchInfo launch_info(argv);
launch_info.SetWorkingDirectory("/tmp");
SBError error;
SBProcess process = target.Launch (launch_info, error);

This will allow you to fill in a SBLaunchInfo from your IDE and possibly keep 
it around for re-use on next launch.

- When attaching, use a SBAttachInfo. Same reason as launch info.

pid_t pid = 123;
SBAttachInfo attach_info(pid)

or

const bool wait_for = true;
SBAttachInfo attach_info("my_program", wait_for);

Then do:

SBProcess process = target.Attach (attach_info, error);

- I would recommend having one thread that is the main LLDB event loop and have 
this event loop also do process control. You can usually use the SBDebugger's 
listener as it will be hooked up by default to the process if you don't specify 
a listener:

SBListener listener = debugger.GetListener();
SBEvent event;
const uint32

Re: [lldb-dev] How to use the C++ API? No useful documentation?

[Greg Clayton via lldb-dev]

Here is the fixed code:

SBListener listener = debugger.GetListener();

SBLaunchInfo launch_info(args);
launch_info.SetEnvironmentEntries(env, true);
launch_info.SetWorkingDirectory("/home/dev/helloWorld");

SBProcess process = target.Launch(launch_info, error);

process.GetBroadcaster().AddListener(listener, 
SBProcess::eBroadcastBitStateChanged | SBProcess::eBroadcastBitSTDOUT);

while(true) 
{
SBEvent event;

if(listener.WaitForEvent(6, event)) 
{
if(!event.IsValid())
break;

const uint32_t event_type = event.GetType();

if (SBProcess::EventIsProcessEvent (event))
{
switch (event_type)
{
case SBProcess::eBroadcastBitStateChanged:
{
const StateType state = SBProcess.GetStateFromEvent(event);
switch (state)
{
case eStateStopped:
{
const uint32_t num_threads = 
process.GetNumThreads();
SBThread thread = process.GetThreadAtIndex(0);
SBStream stream;
thread.GetStatus(stream);
event.GetDescription(stream);
std::cout << stream.GetData() << std::endl;
auto threadStopReason = thread.GetStopReason();   
if (threadStopReason == eStopReasonBreakpoint) 
{
uint64_t bpId = 
thread.GetStopReasonDataAtIndex(0);

if(bpId == static_cast(bp1.GetID())) 
{
std::cout << "Stopped at breakpoint" << 
std::endl;
thread.StepOver();
}
}
else if (threadStopReason == 
eStopReasonPlanComplete) 
{
std::cout << "Stopped at step" << std::endl;
}
}
break;
}
}
break;
case SBProcess::eBroadcastBitSTDOUT:
{
char buffer[1024];
size_t num_bytes = 0;
do 
{
num_bytes = process.GetSTDOUT(buffer, sizeof(buffer));
// Print exactly num_bytes bytes of the string data in 
buffer
if (num_bytes > 0)
printf("%*s", (int)num_bytes, buffer);
} while (num_bytes == sizeof(buffer);
}
break;
}
}
}

Your main issue was you were grabbing threads even when you weren't stopped, 
possibly when you were getting process STDOUT...

The main differences in the code above are:
1 - use SBLaunchInfo to launch
1 - Only try to grab stuff from the process and threads when you are stopped 
(only do process.GetThreadAtIndex(...) when you are stopped, not for every 
event. What would process return if the process is running for 
process.GetThreadAtIndex(0)? Sometimes an invalid thread, sometimes a valid 
thread that might be in the middle of a step. When you are stopped, you are 
guaranteed to get good results. So make sure you are stopped before you ask for 
threads, frames, variables, etc...
2 - Make sure the event is a process event with 
SBProcess::EventIsProcessEvent() as you might get other events if you use the 
debugger's listener (target events, thread events, etc)
3 - Switch off of the event type so you know what kind of event you are getting.

Let me know if this fixes things.

Greg Clayton


> On Feb 23, 2016, at 7:10 PM, paulpee...@gmail.com wrote:
> 
> 
> Thank you very much for that detailed description on explaining the 'basics'.
> 
> I got it working so far but there is a small issue with the code I am 
> currently running. When the main loop (there is only one) receives a 
> breakpoint event and I am trying to get the thread description (After the 
> breakpoint I issue the thread.StepOver command to the next line of code), the 
> result is not 'deterministic' in terms of it is always showing me different 
> current instruction location. Sometimes it's still on the same breakpoint 
> line and sometimes it's on the proper next line. How is it that the thread is 
> still changing even if the stopped state event got hit?
> 
> The code:
> http://pastebin.com/0arNea9m
> 
> Sorry about pastebin, I am sending this from my phone and apparently it 
> discards the code style while copy and paste.
> 
>> On 23 Feb 2016, at 23:40, Greg Clayton  wrote:
>> 
>> I need to spend some time writing this up, but until then here is some info.
>> 
>> We created a python script that uses the LLDB public API to grab a

Re: [lldb-dev] How to use the C++ API? No useful documentation?

[Greg Clayton via lldb-dev]

Not sure. First off, you don't need to do:

process.GetBroadcaster().AddListener(...)

The debugger's listener is already listening to all the events. If you don't 
specify a listener during launch the process will use the debugger's listener 
automatically. If you end up making your own process listener, you would 
actually tell your listener to listen to a broadcaster:

SBListener listener("process-listener");
launch_info.SetListener (listener);
SBProcess process = target.Launch(launch_info, error);

Everything else looks good. 

What happens if you try running using the process_events.py python script? You 
might need to specify the PYTHONPATH environment variable to point to your 
lldb.so

% PYTHONPATH=/path/to/lldb/build/directory python 
lldb/examples/python/process_events.py --breakpoint main.c:12 -- ./a.out arg1 
arg2

Does this work if you replace a.out with the path and args for your program? If 
it does, I would start porting the code from process_events.py and seeing what 
works and what doesn't. The process_events.py will call "process.Continue()" 
after it stops. Feel free to edit and play with this script.


> On Feb 24, 2016, at 3:45 PM, Paul Peet  wrote:
> 
> I am still getting "non determinism".
> 
> This is my current code:
> 
> SBListener listener = debugger.GetListener();
> process.GetBroadcaster().AddListener(listener,
> SBProcess::eBroadcastBitStateChanged |
> SBProcess::eBroadcastBitSTDOUT);
> 
> if(!process.IsValid() || !error.Success()) {
>  return 1;
> }
> 
> error = process.Continue();
> if(!error.Success()) {
>  return 1;
> }
> 
> while(true) {
>  SBEvent event;
> 
>  if(listener.WaitForEvent(6, event)) {
>if(!event.IsValid()) {
>  break;
>}
> 
>const uint32_t event_type = event.GetType();
> 
>if (!SBProcess::EventIsProcessEvent(event)) {
>  continue;
>}
> 
>if(event_type == SBProcess::eBroadcastBitStateChanged) {
>  const StateType state = SBProcess::GetStateFromEvent(event);
> 
>  switch(state) {
>default:
>  continue;
>case eStateStopped: {
>  SBThread thread = process.GetThreadAtIndex(0);
>  SBStream stream;
> 
>  thread.GetStatus(stream);
>  event.GetDescription(stream);
> 
>  std::cout << stream.GetData() << std::endl;
> 
>  auto threadStopReason = thread.GetStopReason();
>  if(threadStopReason == eStopReasonBreakpoint) {
>uint64_t bpId = thread.GetStopReasonDataAtIndex(0);
> 
>if(bpId == static_cast(bp1.GetID())) {
>  std::cout << "Stopped at breakpoint" << std::endl;
>  thread.StepOver();
>}
>  } else if (threadStopReason == eStopReasonPlanComplete) {
>std::cout << "Stopped at step" << std::endl;
>  }
> 
>  break;
>}
>  }
>} else if (SBProcess::eBroadcastBitSTDOUT) {
>  char buffer[1024];
>  size_t num_bytes = 0;
>  do
>  {
>num_bytes = process.GetSTDOUT(buffer, sizeof(buffer));
>if (num_bytes > 0)
>  printf("%*s", (int)num_bytes, buffer);
>  } while (num_bytes == sizeof(buffer));
>}
> 
>std::cout << "--" << std::endl;
>  } else {
>break;
>  }
> }
> 
> It worked at the first try but then I got some strange console output.
> It's not stepping over the instruction anymore. Also the rip is
> basically the same and it's not displaying proper source information
> like it did at the first try.
> 
> Current output:
> 
> * thread #1: tid = 2535, 0x00400830 main`_start, name = 'main'
>frame #0: 0x00400830 main`_start
> main`_start:
>0x400830 <+0>: xorl   %ebp, %ebp
>0x400832 <+2>: movq   %rdx, %r9
>0x400835 <+5>: popq   %rsi
>0x400836 <+6>: movq   %rsp, %rdx
> 0x7ffaac000930 Event: broadcaster = 0xcdefa8 (lldb.process), type =
> 0x0001 (state-changed), data = { process = 0xcdef70 (pid = 2535),
> state = stopped}
> --
> * thread #1: tid = 2535, 0x00400830 main`_start, name =
> 'main', stop reason = breakpoint 1.1
>frame #0: 0x00400830 main`_start
> main`_start:
>0x400830 <+0>: xorl   %ebp, %ebp
>0x400832 <+2>: movq   %rdx, %r9
>0x400835 <+5>: popq   %rsi
>0x400836 <+6>: movq   %rsp, %rdx
> 0x7ffaac001640 Event: broadcaster = 0xcdefa8 (lldb.process), type =
> 0x0001 (state-changed), data = { process = 0xcdef70 (pid = 2535),
> state = stopped}
> Stopped at breakpoint
> --
> Hello World
> --
> 
> It is basically missing the "Stepped at step" part which means lldb
> isn't emitting the PlanCompleteEvent.
> 
> Is it a problem on my system? (Linux?).
> 
> 2016-02-24 19:49 GMT+01:00 Greg Clayton :
>> Here is the fixed code:
>> 
>> SBListener listener = debugger.GetListener();
>> 
>> SBLaunchInfo launch_info(args);
>> launch_info.SetEnvironmentEntries(env, true);
>> launch_info.SetWorkingDirectory("/home/dev/helloWorld");
>> 

Re: [lldb-dev] API for loading debug symbols

[Greg Clayton via lldb-dev]

> On Feb 24, 2016, at 4:21 PM, Mike Gulick via lldb-dev 
>  wrote:
> 
> Hi lldb-dev,
> 
> I'm trying to write some tooling to help with debugging complex builds on 
> Mac.  The libraries all have debugging info separated into .dSYM/ 
> directories.  Due to some complexities in our build system, the .dSYM 
> directories with the debugging info have completely different base paths than 
> the actual library being loaded, and there are multiple different base paths 
> in use for the debug symbols.
> 
> For example,
> 
> Libraries without debugging symbols:
> /path/to/my/workspace/bin/maci64/libA.dylib
> /path/to/my/workspace/bin/maci64/libB.dylib
> /path/to/my/workspace/bin/maci64/libC.dylib
> Corresponding debugging symbols:
> /archive/builds/1234/bin/maci64/libA.dylib.dSYM/Contents/Resources/DWARF/libA.dylib
> /archive/builds/2345/bin/maci64/​libB.dylib.dSYM/Contents/Resources/DWARF/libB.dylib
> /archive/builds/3456/bin/maci64/​libC.dylib.dSYM/Contents/Resources/DWARF/libC.dylib
> 
> I'm looking for an LLDB API (preferably part of the python API) that I can 
> use to load the debug symbols for these libraries when the libraries in my 
> workspace are loaded.
> 
> I've tried using 'lldb.target.AddModule()' to load an additional module after 
> the original module is loaded (using the 4-arg version which allows a 
> separate symfile to be specified).  After doing this though when I call 
> GetNumCompileUnits() on the new module, it still reports 0.  I also have no 
> idea if this module I just added will be used by LLDB instead of the one it 
> originally loaded without debug symbols.
> 
> I've looked at locate_module_and_debug_symbols() in 
> lldb.utils.symbolication.Image (as mentioned here: 
> http://lldb.llvm.org/symbolication.html).  Presumably I could create a custom 
> class which overrides this method, however I didn't see any way to tell LLDB 
> to use this custom method when loading modules.
> 
> I've also looked at the DBGShellCommands described here: 
> http://lldb.llvm.org/symbols.html.  This has several drawbacks, including:
> 1) performance implications (~1000 modules are loaded, constantly in flux so 
> the home-directory-based symlink cache isn't practical)
> 2) no runtime configurability (there doesn't appear to be a way to specify 
> the script as an lldb startup argument, so I need to use the macos 'defaults' 
> tool, and install it in the user's home directory, which means we can't have 
> different scripts in use when debugging multiple different workspaces at the 
> same time).
> 3) no equivalent capability when using lldb on Linux
> 
> I've solved this problem on GDB using the Objfile.add_separate_debug_file() 
> method in their python API: 
> https://sourceware.org/gdb/onlinedocs/gdb/Objfiles-In-Python.html
> 
> I've been scratching my head for a couple of days now.  Does this seem 
> possible, and are there any suggestions for how to proceed?
> 

Yes: use the "target symbols add" to do thing manually:

(lldb) target symbols add --shlib-name 
/path/to/my/workspace/bin/maci64/libA.dylib 
/archive/builds/1234/bin/maci64/libA.dylib.dSYM/Contents/Resources/DWARF/libA.dylib

But, if you are on MacOSX, Spotlight should be locating these files for us and 
should allow us to find them without the need to do anything. You can see if 
spotlight has indexed a dSYM by doing:

% mdls a.out.dSYM
com_apple_xcode_dsym_paths = (
"Contents/Resources/DWARF/a.out"
)
com_apple_xcode_dsym_uuids = (
"C04CC660-24AE-3810-87DF-2CA334E462DD"
)


If you see "com_apple_xcode_dsym_paths" and "com_apple_xcode_dsym_uuids" keys, 
you should be good to go and LLDB should just find the dSYM files for you. 
Spotlight does have a bunch of rules where it doesn't parse in certain 
directories so if you don't see the "com_apple_xcode_dsym_" keys, then it 
might be because of a folder name (the "builds" might stop Spotlight from 
indexing the symbols), but unfortunately Spotlight doesn't say where it will 
and won't parse. One notable issues is it doesn't parse in temporary folders 
("/tmp" or "/var/folders/cf/k0g8rm6d2zq44qzlnw4pbz4w0007k2/T").

If you do see the "com_apple_xcode_dsym_" keys in your mdls output, then 
you can see if spotlight will find your dSYM file by using "mdfind":

% mdfind C04CC660-24AE-3810-87DF-2CA334E462DD
/Volumes/work/gclayton/Documents/src/args/a.out.dSYM

If you see the path to your dSYM file, then LLDB should find the symbols. If 
you disable spotlight, then all bets are off of course.

Greg Clayton

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

Re: [lldb-dev] API for loading debug symbols

[Greg Clayton via lldb-dev]

> On Feb 26, 2016, at 3:06 PM, Mike Gulick  wrote:
> 
> On Thu, 25 Feb 2016 10:18:42 -0800
> Greg Clayton  wrote:
> 
>> 
>> Yes: use the "target symbols add" to do thing manually:
>> 
>> (lldb) target symbols add
>> --shlib-name /path/to/my/workspace/bin/maci64/libA.dylib 
>> /archive/builds/1234/bin/maci64/libA.dylib.dSYM/Contents/Resources/DWARF/libA.dylib
>> 
> 
> Thanks.  I tested this interactively, and it seems to work, although I
> needed to modify the command:
> 
> (lldb) target symbols add 
> /archive/builds/1234/bin/maci64/libA.dylib.dSYM/Contents/Resources/DWARF/libA.dylib
> 
> The '--shlib-name' option doesn't seem to be recognized, but '--shlib'
> is.  However it produced the following error:
> 
> (lldb) target symbols add --shlib /path/to/my/workspace/bin/maci64/libA.dylib 
> /archive/builds/1234/bin/maci64/libA.dylib.dSYM/Contents/Resources/DWARF/libA.dylib
> error: specify either one or more paths to symbol files or using the --file 
> option without arguments
> 
> It looks like the 'target symbols add' without the --shlib does work
> correctly, as I can see the compilation unit and source code when I hit
> breakpoints in the library.  I'm guessing it works by matching the UUID
> of the new library with the UUID of the existing library.
> 
>> But, if you are on MacOSX, Spotlight should be locating these files
>> for us and should allow us to find them without the need to do
>> anything.
> 
> Spotlight is not configured to index these paths.  They are
> autofs-mounted NFS volumes, so they don't appear by default.  The
> archived builds are huge and there are lots of them, so its just
> not practical to index them on each system.  That certainly would be
> convenient if it worked though.
> 

That makes perfect sense. So will this be enough to get you going them?


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

Re: [lldb-dev] How to use the C++ API? No useful documentation?

[Greg Clayton via lldb-dev]

> On Feb 28, 2016, at 2:17 PM, Paul Peet  wrote:
> 
> Hey,
> 
> Just to let you know that I think I made some progress in determine the 
> problem.
> I've basically setup an vm (archlinux, linux 4.4, lldb 3.7.1) and
> tried the code on it. To my surprise it gave me proper output without
> non-determinism. YEY.
> I still don't have any idea why it's not working on my host system. I
> might try testing linux 4.4 like I did on the vm.
> 
> Do you have any idea/suspicion why it might not work on my system. (I
> can provide additional information if needed).

I don't. Maybe some of the linux experts out there might be able to help you. 
Are are working with top of tree LLDB sources right? You might post the exact 
linux setup you have in case that might allow people to help you out...

Greg


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

Re: [lldb-dev] Questions for module/symbol load/unload events

[Greg Clayton via lldb-dev]

In general where you see the event bits defined like SBTarget.h for your case, 
the class that contains the event bit definitions:

class SBTarget
{
public:
//--
// Broadcaster bits.
//--
enum
{
eBroadcastBitBreakpointChanged  = (1 << 0),
eBroadcastBitModulesLoaded  = (1 << 1),
eBroadcastBitModulesUnloaded= (1 << 2),
eBroadcastBitWatchpointChanged  = (1 << 3),
eBroadcastBitSymbolsLoaded  = (1 << 4)
};
...


Also contains all of the static functions that can extract data from those 
events:


class SBTarget
{
public:
...
static bool
EventIsTargetEvent (const lldb::SBEvent &event);

static lldb::SBTarget
GetTargetFromEvent (const lldb::SBEvent &event);

static uint32_t
GetNumModulesFromEvent (const lldb::SBEvent &event);

static lldb::SBModule
GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent &event);


Greg Clayton



> On Feb 29, 2016, at 11:59 AM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> This is very useful, thanks for the info!
> 
> On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:
> 
>> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I am trying to listen for module/symbol load/unload events and display them 
>> in output UI so that debugger users can have a basic clue what is debugger 
>> busy doing while launching a big executable linking many shared libraries.
>> 
>> Questions:
>> 1. I did not find an API to get current load/unload module during module 
>> events. I was expecting some static API like lldb.SBModule(or 
>> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to 
>> treat current PC's module as loading module in module load/unload events. 
>> But that does not work too(I think because process is not stopped in module 
>> load/unload events). Do I miss something here?
> 
> From SBTarget.h:
> 
> static uint32_t
> GetNumModulesFromEvent (const lldb::SBEvent &event);
> 
> static lldb::SBModule
> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent 
> &event);
> 
> Note, you can also cause the process to stop with modules are loaded with the 
> setting:
> 
> target.process.stop-on-sharedlibrary-events
> 
> if that is more convenient for you.
> 
>> 
>> 2. Even though "image list" shows I have around 42 modules loaded in 
>> process, I only got two module load events. Why is that?
> 
> On OS X the loader loads the closure of modules for whatever it is loading, 
> and only stops and informs the debugger when this is all done.  So it is 
> quite usual to see only a few load events even though many modules get loaded.
> 
> 
>> 
>> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there is no 
>> event of type eBroadcastBitSymbolsLoaded generated. Is it expected? 
>> Apparently I have the symbols next to the binary. 
> 
> That event gets sent when symbols are added to an already loaded module.  It 
> is so a UI will know to refresh the backtrace, local variables, source view, 
> etc when code goes from having no symbols to having some symbols.  Those 
> actions are not needed if the library & its symbols get loaded 
> simultaneously, so it isn’t sent in that case.
> 
> Jim
> 
> 
>> 
>> This is tested on mac OSX lldb.
>> 
>> Jeffrey
>> ___
>> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Questions for module/symbol load/unload events

[Greg Clayton via lldb-dev]

As Jim said there really isn't just one address per module. You will want to 
display the address of each of the sections for a module under that module. So 
something like:


a.out
  |- .text @ 0x1
  |- .data @ 0x2
  \- .bss  @ 0x3


> On Feb 29, 2016, at 2:02 PM, Jeffrey Tan  wrote:
> 
> Btw: I did not find an API to retrieve the load address of the SBModule? This 
> seems to be weird to me, did I miss anything?
> 
> 
> On Mon, Feb 29, 2016 at 1:34 PM, Jeffrey Tan  wrote:
> I see why I did not find them in the first place. These two APIs are not 
> listed in the official doc:
> http://lldb.llvm.org/python_reference/index.html
> 
> Someone might want to add it.
> 
> Thanks
> Jeffrey
> 
> On Mon, Feb 29, 2016 at 11:59 AM, Jeffrey Tan  wrote:
> This is very useful, thanks for the info!
> 
> On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:
> 
>> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I am trying to listen for module/symbol load/unload events and display them 
>> in output UI so that debugger users can have a basic clue what is debugger 
>> busy doing while launching a big executable linking many shared libraries.
>> 
>> Questions:
>> 1. I did not find an API to get current load/unload module during module 
>> events. I was expecting some static API like lldb.SBModule(or 
>> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to 
>> treat current PC's module as loading module in module load/unload events. 
>> But that does not work too(I think because process is not stopped in module 
>> load/unload events). Do I miss something here?
> 
> From SBTarget.h:
> 
> static uint32_t
> GetNumModulesFromEvent (const lldb::SBEvent &event);
> 
> static lldb::SBModule
> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent 
> &event);
> 
> Note, you can also cause the process to stop with modules are loaded with the 
> setting:
> 
> target.process.stop-on-sharedlibrary-events
> 
> if that is more convenient for you.
> 
>> 
>> 2. Even though "image list" shows I have around 42 modules loaded in 
>> process, I only got two module load events. Why is that?
> 
> On OS X the loader loads the closure of modules for whatever it is loading, 
> and only stops and informs the debugger when this is all done.  So it is 
> quite usual to see only a few load events even though many modules get loaded.
> 
> 
>> 
>> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there is no 
>> event of type eBroadcastBitSymbolsLoaded generated. Is it expected? 
>> Apparently I have the symbols next to the binary. 
> 
> That event gets sent when symbols are added to an already loaded module.  It 
> is so a UI will know to refresh the backtrace, local variables, source view, 
> etc when code goes from having no symbols to having some symbols.  Those 
> actions are not needed if the library & its symbols get loaded 
> simultaneously, so it isn’t sent in that case.
> 
> Jim
> 
> 
>> 
>> This is tested on mac OSX lldb.
>> 
>> Jeffrey
>> ___
>> 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] Making a new symbol provider

[Greg Clayton via lldb-dev]

> On Feb 29, 2016, at 5:09 PM, Zachary Turner  wrote:
> 
> Suppose you've got two line sequences.  
> 
> First sequence:
> 4198512
> 4198544
> 4198547
> 4198562
> 
> Second sequence:
> 4198528
> 4198531
> 4198537
> 4198552
> 
> These two line sequences overlap, and will not be inserted correctly into a 
> LineTable.  This sounds like a bug to me, because as far as I can tell there 
> is nothing preventing LineSequences being organized this way, but 
> LineTable::InsertSequence assumes that this cannot happen.

Are these addresses or line numbers? If PDB can has its line tables randomly 
ordered, you will need to read all line entries out of the PDB file first into 
one big collection of all line entries, and remember if any are line 
termination entries and then make sequences out of the large collection you end 
up with.

We only expect to get one line entry for a given load address and I believe 
that is reasonable. The registration process for line entries is very DWARF 
centric right now, but I think that the end goal if having line table sequences 
in ascending order that have a single file and line for a given load address is 
a valid assumption.

So it sounds like you just need to read all of your stuff into one large buffer 
and then figure out how you want to register those sequences so they make sense.

In DWARF if you have a line tables like:

0x1000: foo.c line 1
0x1010: foo.c line 2
0x1030: foo.c line 3
0x1040: termination entry

0x2000: foo.c line 11
0x2010: foo.c line 12
0x2020: foo.c line 13
0x2050: termination entry

These are both sequences that define address ranges and we always know the 
address range of each line entry because the last entry in a contiguous line 
sequence always has a last entry to define the size of the last valid (non 
termination entry) line entry. 

How does the PDB file format emit it line table entries? Would it be equivalent 
to the DWARF with no termination entries? Something like:

0x1000: foo.c line 1
0x1010: foo.c line 2
0x1030: foo.c line 3

0x2000: foo.c line 11
0x2010: foo.c line 12
0x2020: foo.c line 13

If that is the case, how do you deal with large gaps like the gap between 
0x1040 and 0x2000?

And if I read what you are saying correctly you are saying your line tables 
might come out like:

0x1000: foo.c line 1
0x2000: foo.c line 11
0x1010: foo.c line 2
0x2010: foo.c line 12
0x1030: foo.c line 3
0x2020: foo.c line 13

Questions:

- Does PDB emit ranges for each line or just a single address?
- Does PDB have termination entries for the equivalent of address 0x1040 and 
0x2050?

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

Re: [lldb-dev] Making a new symbol provider

[Greg Clayton via lldb-dev]

> On Feb 29, 2016, at 5:51 PM, Zachary Turner  wrote:
> 
> 
> 
> On Mon, Feb 29, 2016 at 5:49 PM Zachary Turner  wrote:
> Those are addresses.  Here's the situation I was encountering this on:
> 
> // foo.h
> #include "bar.h"
> inline int f(int n)
> {
> return g(n) + 1;
> }
> 
> // bar.h
> inline int g(int n)
> {
> return n+1;
> }
> 
> // foo.cpp
> #include "foo.h"
> int main(int argc, char** argv)
> {
> return f(argc);
> }
> 
> PDB gives me back line numbers and address range grouped by file.  So I get 
> all of foo.h's lines, all of bar.h's lines, and all of foo.cpp's lines.  In 
> sorted form, the lines for g will appear inside the sequence of lines for f.  
> So that's how the situation was arising.
> 
> Just to clarify here.  When I was encountering this problem, I would create 
> one LineSequence for foo.h's lines, one LineSequence for bar.h's lines, and 
> one for foo.cpp's.  And each one is monotonically increasing, but the ranges 
> can overlap as per the previous explanation, which was causing 
> InsertLineSequence to fail. 


I understand now. Yes, you will need to parse all line entries one big buffer, 
sort them by address, and then figure out what sequences to submit after this.

Is there a termination entry for the last line entry in a function? Lets say 
there were 4096 byte gaps between "f" and "g" and "main"? Are there termination 
entries for the last '}' in each function so that when you put all of the line 
entries into one large collection and sort them by address, that you know there 
is a gap between the line entries? This is very important to get right. If 
there aren't termination entries, you will need to add them manually by looking 
up each line entry address and find the address range of the function (which 
you can cache at the time of making the line sequences from the sorted PDB line 
entries) and add termination entries for the ends of functions. So lets say f 
starts at 0x1000 and the "inline int f" is on line 3, g starts at 0x2000 and 
main starts at 0x3000, you don't want you line table looking like a single 
sequence:

0x1000: foo.cpp line 4  // {
0x1010: foo.cpp line 5  // return g(n) + 1;
0x1020: foo.cpp line 6  // }
0x2000: foo.cpp line 10 // {
0x2010: foo.cpp line 11 // return n+1;
0x2020: foo.cpp line 12 // }
0x3000: foo.cpp line 17 // {
0x3010: foo.cpp line 18 // return f(argc);
0x3020: foo.cpp line 19 // }

If you don't have termination entries, we will think foo.cpp:6 goes from 
[0x1020-0x2000) which is probably now what we want.

There should be termination entries between the functions so that the line 
entries do not contain gaps between functions in their address ranges. So you 
should actually have 3 sequences in the line table:

0x1000: foo.cpp line 4  // {
0x1010: foo.cpp line 5  // return g(n) + 1;
0x1020: foo.cpp line 6  // }
0x1030: END

0x2000: foo.cpp line 10 // {
0x2010: foo.cpp line 11 // return n+1;
0x2020: foo.cpp line 12 // }
0x2030: END

0x3000: foo.cpp line 17 // {
0x3010: foo.cpp line 18 // return f(argc);
0x3020: foo.cpp line 19 // }
0x3030: END

0x1030, 0x2030 and 0x3030 are the end addresses of the functions f, g and main 
respectively. So if your line table only contains start addresses, you will 
need to inject these correctly otherwise source level single step can do the 
wrong thing since it uses line entry address ranges to implement the steps.

Greg

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

Re: [lldb-dev] Questions for module/symbol load/unload events

[Greg Clayton via lldb-dev]

> On Feb 29, 2016, at 11:02 PM, Jeffrey Tan  wrote:
> 
> My assumption is that different sections of the binary will be mapped 
> continuously in memory; and the first section(which should be a header 
> section for the binary) will stands for the base address of the whole module. 
> Is this assumption not true for all platforms? Basically, I would like to 
> show the memory range of the whole module, instead of just text section, so 
> that if a debugger user got a magic address, he can quickly examine the image 
> list to see which binary this address falls into. I guess I can calculate and 
> combine all sections, but it is a bit cumbersome to do. 

That is not correct for all platforms. On MacOSX, any shared library in your 
DYLD shared cache will have its sections mapped all over the place:

libfoo.dylib __TEXT 0x10
barfoo.dylib __TEXT 0x20
libfoo.dylib __DATA 0x810
barfoo.dylib __TEXT 0x820
libfoo.dylib __OBJC 0x910
barfoo.dylib __OBJC 0x920

So you can't make any assumptions. That being said, each platform has the 
notion of where a library is actually loaded. For MacOSX, this is the address 
of the __TEXT segment. Not sure for other platforms.

The easy thing for you to do it to show the largest address range that contains 
all sections in a shared library. Get all sections from the module and then 
calculate the min and max address of all sections and then use the largest 
address range so show the addresses that the shared library could contain. It 
doesn't mean that a shared library does contain and address since the above 
shared libraries from my example above would be something like:


libfoo.dylib [0x10 - 0x91f]
barfoo.dylib [0x20 - 0x92f]


Note that they overlap, but this does show correct info to the user... 


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

Re: [lldb-dev] Making a new symbol provider

[Greg Clayton via lldb-dev]

> On Mar 1, 2016, at 11:30 AM, Zachary Turner  wrote:
> 
> We do know the last line of a function. In the review i posted, you can see 
> the condition where i set is_epilogue to true. That is the last line of a 
> function corresponding to the } (although the function may contain additional 
> bytes, since that only refers to the first byte of the epilogue.

I don't believe any compilers set is_eqilogue correctly yet.

> But I don't know if it's appropriate to set is_terminal_entry to true here 
> because that's a valid line with a valid address. Terminal entries are 
> ignored when doing address lookups so this line would never be found when 
> looking up that address.

The "is_terminal_entry" are to provide the address range for the last line in a 
sequence. It's line number doesn't mean anything, but it is typically the same 
as the previous one.
> 
> What i might be able to do is figure out the size of the epilogue and inject 
> a new entry with address=epilogue_addr+epilogue_size and make that the 
> termination entry does that work? If so what should i set for its line number?

The line number can just be the same as the previous one. We need to make sure 
we cover every byte of a function with a valid line entry. Anywhere the user 
can actually stop should have a valid line entry when possible.
> 
> Just to make sure I understand, does "terminal entry" specifically mean the 
> end of a *function*? Reading the code I thought it meant the end of a 
> LineSequence

No, it just is there to indicate that it terminates the previous line entry 
since line entries are stored with start address only. If a function is 
discontiguous, or if it has data in the middle, a function might have multiple 
sequences. So the terminal entry is just to provide an address range for the 
last line entry in a contiguous address range of line entries.

> On Tue, Mar 1, 2016 at 10:33 AM Greg Clayton  wrote:
> 
> > On Feb 29, 2016, at 5:51 PM, Zachary Turner  wrote:
> >
> >
> >
> > On Mon, Feb 29, 2016 at 5:49 PM Zachary Turner  wrote:
> > Those are addresses.  Here's the situation I was encountering this on:
> >
> > // foo.h
> > #include "bar.h"
> > inline int f(int n)
> > {
> > return g(n) + 1;
> > }
> >
> > // bar.h
> > inline int g(int n)
> > {
> > return n+1;
> > }
> >
> > // foo.cpp
> > #include "foo.h"
> > int main(int argc, char** argv)
> > {
> > return f(argc);
> > }
> >
> > PDB gives me back line numbers and address range grouped by file.  So I get 
> > all of foo.h's lines, all of bar.h's lines, and all of foo.cpp's lines.  In 
> > sorted form, the lines for g will appear inside the sequence of lines for 
> > f.  So that's how the situation was arising.
> >
> > Just to clarify here.  When I was encountering this problem, I would create 
> > one LineSequence for foo.h's lines, one LineSequence for bar.h's lines, and 
> > one for foo.cpp's.  And each one is monotonically increasing, but the 
> > ranges can overlap as per the previous explanation, which was causing 
> > InsertLineSequence to fail.
> 
> 
> I understand now. Yes, you will need to parse all line entries one big 
> buffer, sort them by address, and then figure out what sequences to submit 
> after this.
> 
> Is there a termination entry for the last line entry in a function? Lets say 
> there were 4096 byte gaps between "f" and "g" and "main"? Are there 
> termination entries for the last '}' in each function so that when you put 
> all of the line entries into one large collection and sort them by address, 
> that you know there is a gap between the line entries? This is very important 
> to get right. If there aren't termination entries, you will need to add them 
> manually by looking up each line entry address and find the address range of 
> the function (which you can cache at the time of making the line sequences 
> from the sorted PDB line entries) and add termination entries for the ends of 
> functions. So lets say f starts at 0x1000 and the "inline int f" is on line 
> 3, g starts at 0x2000 and main starts at 0x3000, you don't want you line 
> table looking like a single sequence:
> 
> 0x1000: foo.cpp line 4  // {
> 0x1010: foo.cpp line 5  // return g(n) + 1;
> 0x1020: foo.cpp line 6  // }
> 0x2000: foo.cpp line 10 // {
> 0x2010: foo.cpp line 11 // return n+1;
> 0x2020: foo.cpp line 12 // }
> 0x3000: foo.cpp line 17 // {
> 0x3010: foo.cpp line 18 // return f(argc);
> 0x3020: foo.cpp line 19 //  }
> 
> If you don't have termination entries, we will think foo.cpp:6 goes from 
> [0x1020-0x2000) which is probably now what we want.
> 
> There should be termination entries between the functions so that the line 
> entries do not contain gaps between functions in their address ranges. So you 
> should actually have 3 sequences in the line table:
> 
> 0x1000: foo.cpp line 4  // {
> 0x1010: foo.cpp line 5  // return g(n) + 1;
> 0x1020: foo.cpp line 6  // }
> 0x1030: END
> 
> 0x2000: foo.cpp line 10 // {
> 0x2010: foo.cpp lin

Re: [lldb-dev] Making a new symbol provider

[Greg Clayton via lldb-dev]

On Mar 1, 2016, at 11:45 AM, Zachary Turner  wrote:
> 
> Alright I think i get it. Basically terminal entry means "everything from 
> this address onwards is not part of any function"

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

Re: [lldb-dev] How to enumerate stopped threads in C++ API?

[Greg Clayton via lldb-dev]

Each call into the lldb::SB* API will take a target lock and possible a process 
read/write lock. 

We do have a SBThreadCollection class that we can use. Feel free to add an API 
like this to SBProcess:


class SBProcess
{
SBThreadCollection GetThreads();
};

class SBThreadCollection
{
SBThreadCollection GetThreadsWithStopReasons();
};


The current API on process SBProcess::GetNumThreads() and 
SBProcess::GetThreadAtIndex() might have issues if you are doing things like 
evaluating an expression on another thread where you might request the number 
of threads and get 10, but then an expression runs on another thread and there 
are now maybe 8 or 12 threads, and then you call SBProcess::GetThreadAtIndex() 
and it might return you results that are different that what you wanted. If we 
return all threads at once, we won't run into this issue. Then you can have 
SBThreadCollection add a new methods to return a new list for all threads with 
stop reasons.

That being said, hundreds of threads should not cause a huge bottleneck for 
single stop, but if you doing it many many many times it could be. 

Greg Clayton

> On Mar 3, 2016, at 9:54 AM, Eugene Birukov via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I am working on a custom debugger on Linux and I am using LLDB C++ API for 
> that. So far, from the functionality point of view the life is good, but I am 
> running into severe performance issue.
> 
> The problem is that the target application has literally hundreds of threads, 
> and when the target process stops, I need to identify all the threads that 
> have non-trivial stop reason. So, I am doing something like that:
> 
> // Loop over threads
> int numThreads = m_Process.GetNumThreads();
> for (int threadIndex = 0; threadIndex < numThreads; ++threadIndex)
> {
> // Inspect the thread state
> sbThread = m_Process.GetThreadAtIndex(threadIndex);
> stopReason = sbThread.GetStopReason();
> ...
> 
> 
> Well, this loop turns out to be a bottleneck. 
> 
> So, is there any way to find all the stopped threads without iterating over 
> the whole world?
> 
> Thanks,
> Eugene
> 
> 
> ___
> 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] How to use the C++ API? No useful documentation?

[Greg Clayton via lldb-dev]

> On Mar 4, 2016, at 8:08 AM, Paul Peet via lldb-dev  
> wrote:
> 
> Hi Pavel,
> 
> First of all, thank you for looking into this. I really appreciate it.
> Secondly,  the check with GetRestartedFromEvent did the trick.
> I am finally getting correct information. Thank You very much.

I would like to note that the initial Python implementation I pointed you at 
does check the restarted bit. Glad this fixes your issues.

> 
> About the documentation, I really think it can be much better and I
> would also help in this case but my english isn't my first language as
> I am also not good at expressing the intention of every lldb feature
> because obviously I am also just a beginner.
> 
> Although I think it would be helpful for other users, that if there
> would have been a valid C++ debugging example like my issue
> reproduction code.

We, and by we I mean Jim Ingham and myself, need to document this better. If 
you have a summary of the issues you ran into and what wasn't clear about the 
APIs, please let us know so we don't miss something when we write up the 
documentation.

Greg Clayton

> :)
> 
> ~Paul
> 
> 
> 
> 2016-03-04 13:09 GMT+01:00 Pavel Labath :
>> Hi Paul,
>> 
>> I believe you are experiencing the same problem as a couple of other
>> people before you (see
>> ,
>> ).
>> Basically, you need to ignore the events with the "restarted" flag  by
>> checking the GetRestartedFromEvent value for Stopped events. Linux
>> broadcasts this event on initial start, but other targets don't. This
>> is not a particularly well documented feature, and we would welcome
>> any improvements to the documentation. :)
>> 
>> Let me know if you still have problems after adding the check for the
>> restarted flag.
>> 
>> cheers,
>> pl
>> 
>> 
>> On 3 March 2016 at 15:26, Pavel Labath  wrote:
>>> Thanks for the explanation. I'll look this over tomorrow.
>>> 
>>> cheers,
>>> pl
>>> 
>>> On 3 March 2016 at 15:23, Paul Peet  wrote:
 Hi Pavel,
 
 This is the code:
 
 int main() {
  using namespace lldb;
 
  SBDebugger::Initialize();
  SBDebugger debugger = SBDebugger::Create(true);
 
  if(!debugger.IsValid()) {
return 1;
  }
 
  SBTarget target = 
 debugger.CreateTarget("/home/cynecx/dev/helloWorld/main");
 
  if(!target.IsValid()) {
return 1;
  }
 
  SBBreakpoint bp1 = target.BreakpointCreateByLocation(
"/home/cynecx/dev/helloWorld/main.cpp", 7);
 
  if(!bp1.IsValid()) {
return 1;
  }
 
  bp1.SetEnabled(true);
 
  const char* args[] = { "/home/cynecx/dev/helloWorld/main", 0 };
  const char* env[] = { 0 };
 
  SBLaunchInfo launch_info(args);
  launch_info.SetEnvironmentEntries(env, true);
  launch_info.SetWorkingDirectory("/home/cynecx/dev/helloWorld");
  launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
 
  SBError error;
  SBProcess process = target.Launch(launch_info, error);
 
  if(!process.IsValid() || !error.Success()) {
return 1;
  }
 
  error = process.Continue();
  if(!error.Success()) {
return 1;
  }
 
  while(true) {
SBEvent event;
SBListener listener = debugger.GetListener();
 
if(listener.WaitForEvent(6, event)) {
  if(!event.IsValid()) {
break;
  }
 
  const uint32_t event_type = event.GetType();
 
  if (!SBProcess::EventIsProcessEvent(event)) {
continue;
  }
 
  if(event_type == SBProcess::eBroadcastBitStateChanged) {
const StateType state = SBProcess::GetStateFromEvent(event);
 
switch(state) {
  default:
continue;
  case eStateStopped: {
 //static bool runOnce = false;
 //
 //if(runOnce == false) {
 //  sleep(1);
 //  runOnce = true;
 //}
 
SBThread thread = process.GetThreadAtIndex(0);
SBStream stream;
 
thread.GetStatus(stream);
event.GetDescription(stream);
 
std::cout << stream.GetData() << std::endl;
 
auto threadStopReason = thread.GetStopReason();
if(threadStopReason == eStopReasonBreakpoint) {
  uint64_t bpId = thread.GetStopReasonDataAtIndex(0);
 
  if(bpId == static_cast(bp1.GetID())) {
std::cout << "Stopped at breakpoint" << std::endl;
thread.StepOver();
  }
} else if (threadStopReason == eStopReasonPlanComplete) {
  std::cout << "Stopped at step" << std::endl;
}
 
break;
  }
   

Re: [lldb-dev] How to set source line breakpoint using BreakpointCreateByLocation?

[Greg Clayton via lldb-dev]

Not sure why we aren't treating this as a relative path. Probably because of 
the 1000 '/' characters. Feel free to dig into lldb_private::FileSpec and play 
around and see where things are going wrong.

You can probably fix LLDB, when it resolves paths, to clean this up, but we 
typically don't resolve paths that we find in debug info when we run into it. 
Why? Because if you have DWARF info that contains paths that map to 1 files 
that exist on network file system mounts, we would need to resolve all of those 
paths as we parse the line tables and calling stat() on all these files take a 
TON of time. So we won't resolve paths we find in debug info typically. We 
could try and run a path resolving function that doesn't call stat() to fix up 
an really bad paths like the ones that your build system is making, but we 
don't have support for that right now due to the network file system stat() 
issue.

Greg

> On Mar 5, 2016, at 11:47 AM, Jeffrey Tan  wrote:
> 
> Ooops, I accidentally dropped lldb mail list.
> I have chatted this long relative path issue with our buck build team, they 
> seem to do some kind of post-processing for the symbol files but failed to 
> run another scripts to resolve the processed paths back into absolute path. 
> And they are unable to fix this in short time. :-(
> 
> I am building a workaround for this issue:
> I am building a middle indirection map between debugger UI and lldb. Whenever 
> I enumerate a SBFileSpec a source line, I get the source file long relative 
> path from it and add basepath of the build project then normalize into an 
> absolute path, then store absolute_path->SBFileSpec mapping into the map, 
> then send the absolute path to debugger UI. When the debugger UI is trying to 
> set source line breakpoint, I got the absolute path back from debugger UI and 
> use the middle indirection map to find corresponding SBFileSpec for that 
> source file. Finally, I used the SBFileSpec to set source line breakpoint. 
> The assumption is that as long as I used the same SBFileSpec from lldb, I 
> should use it to set source line breakpoint successfully.
> However, it turns out this still does not work. The breakpoints are listed as 
> pending:
> 
> break list
> Current breakpoints:
> 1: file = 
> './/Apps/Internal/MPKEats/MPKEats/App/main.m',
>  line = 9, locations = 0 (pending)
> 2: file = 
> './/Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m',
>  line = 20, locations = 0 (pending)
> 
> Questions:
> Isn't lldb treating this long relative path as *absolute path* so as long as 
> this long path is used to set breakpoint it should work? Any idea why this 
> workaround approach does not work?
> 
> Jeffrey
> 
> On Wed, Jan 6, 2016 at 8:47 AM, Jeffrey Tan  wrote:
> Nevermind, I do not know why 
> "GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m", line)" 
> does not work for me last October. I tried it again, it works now. 
> I will see if I can figure out the weird relative location path in symbol 
> file issue.
> 
> Thanks!
> 
> On Tue, Jan 5, 2016 at 3:38 PM, Jeffrey Tan  wrote:
> Sorry for the late response. I finally had time to come back to this issue. 
> 
> Can anyone help me with the 
> "self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
>  line)" not working issue? Does it suppose to work? I can reproduce it pretty 
> easily in a small python script. 
> 
> I found the following lldb test that uses this API:
> http://www.opensource.apple.com/source/lldb/lldb-69/test/lang/objc/objc-stepping/TestObjCStepping.py
> 
> So it seems that this should work. Am I doing something wrong? I am importing 
> the Xcode's lldb by following:
> developer_dir = subprocess.check_output(['xcode-select', '--print-path'])
> lldb_pythonpath = os.path.join(
> developer_dir.strip(), 
> '../SharedFrameworks/LLDB.framework/Resources/Python')
> sys.path.append(lldb_pythonpath)
> 
> For the weird long path issue, I will follow-up with our build team, but 
> definitely needs to resolve the BreakpointCreateByLocation() can't be called 
> issue first. 
> 
> Thanks for any help!
> Jeffrey
> 
> On Thu, Oct 8, 2015 at 10:46 AM, Greg Clayton  wrote:
> 
> > On Oct 8, 2015, at 10:25 AM, Jeffrey Tan  wrote:
> >
> > Thanks Greg. Here is the info:
> > (lldb) br list --verbose
> > Current breakpoints:
> > 1: file = 'EATAnimatedView.m', line = 21
> > 1.1:
> >   module = 
> > /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/12E85C41-A74

Re: [lldb-dev] Question about building line tables

[Greg Clayton via lldb-dev]

> On Mar 7, 2016, at 3:07 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> This discussion originally started on a code review thread, but I figured I 
> would continue it here since the patch has landed and I want to do more work 
> as a followup.
> 
> So LLDB's LineTable data structures have the notion of a "terminal entry".  
> As I understand it, LineTables are structured as a sequence of "entries".  An 
> entry consists of:
> 
> Start Line
> End Line
> Start Address
> Byte Length
> Is Terminal Entry

Not quite correct. There is no end line and there is no byte length. To 
efficiently store line entries that can be efficiently searched, we need to not 
have a length and not have an end line.

> and this represents some piece of source code.  If you were to examine all 
> line entries in the debug info, you would find that not all address ranges 
> are covered.  For example, line 10 might correspond to address 0x12345 - 
> 0x12347, and line 11 might correspond to address 0x12360.  So address 0x12348 
> - 0x12359 do not map to anything.  Probably they are not even code, but just 
> space between functions, or other random data in the .text section of a 
> binary that isn't code.
> 
> The problem is, building a line table requires the person parsing the debug 
> info to specify where the terminal entries are.  Why?  Isn't it trivial to 
> calculate this automatically?  Say you insert a bunch of line entries, now 
> they're all sorted by address into some array of LineEntry structures.  It 
> seems to me like n is a terminal entry if 
> 
> (entries[n].address + entries[n].length) < entries[n+1].address
> 
> is true.  Why do we need to store a separate flag for it?

Because there is no size in each LineEntry. We rely on the next line entry 
always terminating the previous one. So one marked with "i am a terminal entry" 
is required to finish off the previous one.

> Is there ever a case where the above condition is true but it is not the end 
> of a sequence?  Or where the above condition is false but it is the end of a 
> sequence?

Not sure these questions apply after what I said above.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Question about building line tables

[Greg Clayton via lldb-dev]

The one thing that might confuse you is we actually store line entries using 
lldb_private::LineTable::Entry structures which do not have the byte size or 
the file as a FileSpec:

class LineTable {
protected:
  struct Entry
  {
lldb::addr_t file_addr; ///< The file address for this 
line entry
uint32_tline;   ///< The source line number, or 
zero if there is no line number information.
uint16_tcolumn; ///< The column number of the 
source line, or zero if there is no column information.
uint16_tfile_idx:11,///< The file index into 
CompileUnit's file table, or zero if there is no file information.
is_start_of_statement:1,///< Indicates this entry is 
the beginning of a statement.
is_start_of_basic_block:1,  ///< Indicates this entry is 
the beginning of a basic block.
is_prologue_end:1,  ///< Indicates this entry is 
one (of possibly many) where execution should be suspended for an entry 
breakpoint of a function.
is_epilogue_begin:1,///< Indicates this entry is 
one (of possibly many) where execution should be suspended for an exit 
breakpoint of a function.
is_terminal_entry:1;///< Indicates this entry is 
that of the first byte after the end of a sequence of target machine 
instructions.
  };
};

These are 16 bytes each since the file is represented as a file index and we 
only have the "lldb::addr_t file_addr" for the address.

But we dress them up into lldb_private::LineEntry structures for all other 
clients that consume line entries and those structures _do_ have information 
like the user wants to see it:

struct LineEntry
{
AddressRangerange;  ///< The section offset address 
range for this line entry.
FileSpecfile;
uint32_tline;   ///< The source line number, or 
zero if there is no line number information.
uint16_tcolumn; ///< The column number of the 
source line, or zero if there is no column information.
uint16_tis_start_of_statement:1,///< Indicates this entry is 
the beginning of a statement.
is_start_of_basic_block:1,  ///< Indicates this entry is 
the beginning of a basic block.
is_prologue_end:1,  ///< Indicates this entry is 
one (of possibly many) where execution should be suspended for an entry 
breakpoint of a function.
is_epilogue_begin:1,///< Indicates this entry is 
one (of possibly many) where execution should be suspended for an exit 
breakpoint of a function.
is_terminal_entry:1;///< Indicates this entry is 
that of the first byte after the end of a sequence of target machine 
instructions.

};

Each instance is 64 bytes and quite a bit more expensive to copy around.




> On Mar 7, 2016, at 3:13 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> 
>> On Mar 7, 2016, at 3:07 PM, Zachary Turner via lldb-dev 
>>  wrote:
>> 
>> This discussion originally started on a code review thread, but I figured I 
>> would continue it here since the patch has landed and I want to do more work 
>> as a followup.
>> 
>> So LLDB's LineTable data structures have the notion of a "terminal entry".  
>> As I understand it, LineTables are structured as a sequence of "entries".  
>> An entry consists of:
>> 
>> Start Line
>> End Line
>> Start Address
>> Byte Length
>> Is Terminal Entry
> 
> Not quite correct. There is no end line and there is no byte length. To 
> efficiently store line entries that can be efficiently searched, we need to 
> not have a length and not have an end line.
> 
>> and this represents some piece of source code.  If you were to examine all 
>> line entries in the debug info, you would find that not all address ranges 
>> are covered.  For example, line 10 might correspond to address 0x12345 - 
>> 0x12347, and line 11 might correspond to address 0x12360.  So address 
>> 0x12348 - 0x12359 do not map to anything.  Probably they are not even code, 
>> but just space between functions, or other random data in the .text section 
>> of a binary that isn't code.
>> 
>> The problem is, building a line table requires the person parsing the debug 
>> info to specify where the terminal entries are.  Why?  Isn't it trivial to 
>> calculate this automatically?  Say you insert a bunch of line entries, now 
>> they're all sorted by address into some array of LineEntry structures.  It 
>> seems to me like n is a terminal entry i

Re: [lldb-dev] Question about building line tables

[Greg Clayton via lldb-dev]

> On Mar 7, 2016, at 3:21 PM, Zachary Turner  wrote:
> 
> Does DWARF not store this information?  Because it seems like it could be 
> efficiently stored in an interval tree, the question is just whether it is 
> efficient to convert what DWARF stores into that format.

No it stores it just like we do, but in a compressed format that is useless for 
searching.

> PDB returns line entries in the format I described, with a start address and 
> a byte length, so to determine whether something is a terminal entry I have 
> to add them to some kind of data structure that collapses ranges and then 
> manually scan through for breaks in the continuity of the range.
> 
> Is there some way we can make this more generic so that it's efficient for 
> both DWARF and PDB?

We need an efficient memory format that LLDB can use to search things, which is 
how things currently are done: all plug-ins are expected to parse debug info 
and make a series of lldb_private::LineTable::Entry structs.

We could defer this functionality into the plug-ins directly where you always 
must say "hey SymbolFile, here is a section offset address, please get me the 
lldb_private::LineEntry:

bool
SymbolFile::GetLineEntryForAddress (const lldb_private::Address &addr, 
lldb_private::LineEntry &line_entry);

The thing I don't like about this approach where we don't supply the format we 
want the line tables to be in is this does make it quite painful to iterate 
over all line table entries for a compile unit. You would need to get the 
address range for all functions in a compile unit, then make a loop that would 
iterate through all addresses and try to lookup each address to find the 
lldb_private::LineEntry for that address. Right now we just get the LineTable 
from the compile unit and say "bool LineTable::GetLineEntryAtIndex(uint32_t 
idx, LineEntry &line_entry);". 


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

Re: [lldb-dev] How to set source line breakpoint using BreakpointCreateByLocation?

[Greg Clayton via lldb-dev]

> On Mar 7, 2016, at 4:08 PM, Jeffrey Tan  wrote:
> 
> Hi Greg,
> 
> I am not sure if I understand the behavior here: the long relative file path 
> from our build system does *not* exist on file system, do you mean lldb will 
> always try to resolve this relative path to a *real* file on file system 
> using stat() call?

No it doesn't do that and that is why you path remains as is.

> And it will fail to bind the breakpoint if can't find the resolved file path? 

No it shouldn't if you set it by basename. If it does fail to set the 
breakpoint using "EATAnimatedView.m" as the filename, then it is a bug.

> 
> Per my testing, I was able to use #1. "b EATAnimatedView.m:33" to bind 
> breakpoint, but not: 
> #2, "b 
> .//Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:20"

That is interesting, and you will need to track down why this is happening. 
Obviously we are expecting this kind of path and something is going wrong.

> break list --verbose
> Current breakpoints:
> 2: file = 
> './/Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m',
>  line = 20
> 
> 3: file = 'EATAnimatedView.m', line = 33
> 3.1: 
>   module = 
> /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/32967F60-A4C3-43DC-ACA8-92D819413362/data/Containers/Bundle/Application/96DA24F5-E35D-402F-B4B7-1C5BBD40B270/MPKEats.app/MPKEats
>   compile unit = EATAnimatedView.m
>   function = -[EATAnimatedView 
> initWithFrame:imageNames:animationDuration:repeatCount:touchEnabled:]
>   location = 
> ./Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:33
>   address = 0x00010a1ff798
>   resolved = true
>   hit count = 0   
> 
> Do you mean #2 should work?

I would expect #2 to work, but not surprised it doesn't.

> I think I am a bit vague on how source breakpoint is supposed to work. What 
> is the algorithm to successfully bind breakpoint here? 

What we currently do is break all file paths up into a basename 
(EATAnimatedView.m) and a directory 
(.//Apps/Internal/MPKEats/MPKEats/View).
 

We break up filenames like this because the user will rarely type full paths in 
commands. IDEs will often give us full paths to files, but users rarely do. So 
to efficiently store files and make them easy to compare, we split the path up 
into two strings. Each string gets constified by being placed into a 
ConstString object that uniques the string and gives out the same pointer for 
each string it uniques so we can use pointer comparisons to compare two 
strings. FileSpec objects contain:

class FileSpec 
{
protected:
//--
// Member variables
//--
ConstString m_directory;///< The uniqued directory path
ConstString m_filename; ///< The uniqued filename path
mutable bool m_is_resolved; ///< True if this path has been resolved.
PathSyntax m_syntax;///< The syntax that this path uses (e.g. 
Windows / Posix)
};


So we can easily compare strings. You should probably step through some code 
and figure out why things are not matching up. The FileSpec class has some 
functions that try to clean up paths without calling stat:

void
FileSpec::NormalizePath ();

void
FileSpec::RemoveBackupDots (const ConstString &input_const_str, ConstString 
&result_const_str);

And a few others. They might be causing the problems. You will need to debug 
this if you wish to figure out what is going wrong.

A few tests that I ran include:

(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> f = 
>>> lldb.SBFileSpec('.//Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m',
>>>  False)
>>> print

Re: [lldb-dev] How to set source line breakpoint using BreakpointCreateByLocation?

[Greg Clayton via lldb-dev]

> On Mar 7, 2016, at 5:27 PM, Jeffrey Tan  wrote:
> 
> Thanks for the info, I will debug this.
> One more quick question related to this: in full path breakpoint case(IDE 
> scenario), do we compare both file name and directory path exact match and 
> bind breakpoint successfully? I ask this because of the breakpoint issue I 
> found:
> 1. I have a symbolic link folder "/home/jeffreytan/foo/" which points to 
> "/data/users/jeffreytan/bar/foo". 
> 2. If I built cpp file in /home/jeffreytan/foo/, and try to set breakpoint 
> using real path "b /data/users/jeffreytan/bar/foo/main.cpp:10" it will fail 
> to bind.
> 3. While "b /home/jeffreytan/foo//main.cpp:10" binds fine, vise verse.

Yep, that will fail for the reason that "/home/jeffreytan/foo" won't match 
"/data/users/jeffreytan/bar/foo" and we don't resolve paths on debug info 
because of the cost as we mentioned before.

> 
> I can't control how users open/build file in our IDE, they may choose to 
> open/build from symbolic link folder or real path folder. What is the general 
> suggestion to deal with symbolic link differences?

There isn't a good one right now. One idea is to try and track the project 
directory in your IDE, like "/home/jeffreytan/foo", and note that this is the 
base directory. Then have the IDE always set the breakpoint by basename 
("main.cpp") and then filter the results out based on where the file is in the 
project directory. So if you have your main file in your project directory as 
"src/main.cpp", you would set a breakpoint in main.cpp, and then look at the 
locations that the breakpoint had and disable any locations that don't have a 
matching parent directory of "src"...

Greg

> 
> Jeffrey
> 
> 
> 
> 
> On Mon, Mar 7, 2016 at 4:25 PM, Greg Clayton  wrote:
> 
> > On Mar 7, 2016, at 4:08 PM, Jeffrey Tan  wrote:
> >
> > Hi Greg,
> >
> > I am not sure if I understand the behavior here: the long relative file 
> > path from our build system does *not* exist on file system, do you mean 
> > lldb will always try to resolve this relative path to a *real* file on file 
> > system using stat() call?
> 
> No it doesn't do that and that is why you path remains as is.
> 
> > And it will fail to bind the breakpoint if can't find the resolved file 
> > path?
> 
> No it shouldn't if you set it by basename. If it does fail to set the 
> breakpoint using "EATAnimatedView.m" as the filename, then it is a bug.
> 
> >
> > Per my testing, I was able to use #1. "b EATAnimatedView.m:33" to bind 
> > breakpoint, but not:
> > #2, "b 
> > .//Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:20"
> 
> That is interesting, and you will need to track down why this is happening. 
> Obviously we are expecting this kind of path and something is going wrong.
> 
> > break list --verbose
> > Current breakpoints:
> > 2: file = 
> > './/Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m',
> >  line = 20
> >
> > 3: file = 'EATAnimatedView.m', line = 33
> > 3.1:
> >   module = 
> > /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/32967F60-A4C3-43DC-ACA8-92D819413362/data/Containers/Bundle/Application/96DA24F5-E35D-402F-B4B7-1C5BBD40B270/MPKEats.app/MPKEats
> >   compile unit = EATAnimatedView.m
> >   function = -[EATAnimatedView 
> > initWithFrame:imageNames:animationDuration:repeatCount:touchEnabled:]
> >   location = 
> > ./Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:33
> >   address = 0x00010a1ff798
> >   resolved = true
> >   hit count = 0
> >
> > Do you mean #2 should work?
> 
> I would expect #2 to work, but not surprised it doesn't.
> 
> > I think I am a bit vague on how source breakpoint is supposed to work. What 
> > is the algorithm to successfully bind breakpoint here?
> 
> What we currently do is break all file paths up into a basename 
> (EATAnimatedView.m) and a directory 
> (.//Apps/Internal/MPKEats/MPKEats/View).
> 
> We break up filenames like this because the user will rarely type full paths 
> in commands. IDEs

Re: [lldb-dev] Inquiry about Load Address

[Greg Clayton via lldb-dev]

If you are connected to a live process, you just need to look up the 
lldb::SBAddress for a load address using the SBTarget


lldb::SBTarget target = ...;
lldb::addr_t load_addr = ...;
lldb::SBAddress addr = target.ResolveLoadAddress (load_addr);
if (addr.GetSection().IsValid())
{
// Load address mapped to an address that is in a section from a SBModule
}
else
{
// Address doesn't map to a known section and is probably on the stack or 
heap
}

Also note that once you have an SBAddress (which is a section + offset address) 
you can easily find all of the things it maps to (executable (SBModule), source 
file (SBCompileUnit), function (SBFunction), etc). 

Using the "addr" we looked up above you can find out what "addr" maps to:

lldb::SBModule module = addr.GetModule();

The following items will be available if you have debug info for your 
executable:

lldb::SBCompileUnit cu = addr.GetCompileUnit ();
lldb::SBFunction function = addr.GetFunction ();
lldb::SBBlock block = addr.GetBlock();
lldb::SBLineEntry line_entry = addr.GetLineEntry ();

And the following will be available if you have a valid symbol table (you 
haven't stripped your binary):

lldb::SBSymbol symbol = addr.GetSymbol();


Any of the objects above might be invalid, just use "IsValid()" on them to test 
if they are valid. A load address might be in a section (.data + 10023) but it 
might not map to a compile unit, function, block or line entry...

Also note that you can easily get to the disassembly instructions for the 
function or symbol very easily:

lldb::SBInstructionList instructions;
if (function.IsValid())
instructions = function.GetInstructions(target);
else if (symbol.IsValid())
instructions = symbol.GetInstructions(target);

Now you have a list of all instructions for a given function (if you have debug 
info) or symbol (if you don't have debug info):

if (instructions.IsValid())
{
const size_t num_instructions = instructions.GetSize();
if (num_instructions > 0)
{
for (size_t inst_idx=0; inst_idx On Mar 8, 2016, at 4:53 AM, Ravitheja Addepally via lldb-dev 
>  wrote:
> 
> Ok, I am currently in the process of developing Intel Processor trace support 
> for LLDB , I need the virtual address mappings for the Elf's for decoding the 
> trace data. I will check if SBSection.GetSectionData will work or not , 
> Thanks for the info.
> 
> On Tue, Mar 8, 2016 at 12:11 PM, Pavel Labath  wrote:
> Hi,
> 
> could you give us a bit more background about what are you trying to
> do? It's hard to answer the question without knowing a bit more...
> 
> On 8 March 2016 at 10:42, Ravitheja Addepally via lldb-dev
>  wrote:
> > Hello,
> >   I wanted to know if there is any existing API or a set of API's that
> > could be used to retrieve the load addresses of the Modules ?
> 
> There is a GetLoadAddress function on SBSection
> .
> I don't see one on SBModule though. What do you need this for?
> 
> > secondly Can
> > we obtain the dumps of the loaded Elf 's like in the remote case
> > transporting them from the target to the host ?
> >
> 
> What kind of "dumps" are you looking for? Will
> SBSection.GetSectionData() work? A lot of other data is available in
> the other SB classes, but it's hard to answer this without knowing
> what exactly you are looking for.
> 
> pl
> 
> ___
> 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] Question about building line tables

[Greg Clayton via lldb-dev]

Yep
> On Mar 8, 2016, at 12:56 PM, Zachary Turner  wrote:
> 
> Let's suppose I've got this function (ignore the operands to branch 
> instructions, I disassembled a real function and just manually adjusted 
> addresses on the left side only just to create a contrived example).  
> 
> infinite-dwarf.exe`main at infinite.cpp:5
>4
>5int main(int argc, char **argv) {
>6int n = 0;
> infinite-dwarf.exe`main:
> infinite-dwarf.exe[0x41] <+0>:   55push   ebp
> infinite-dwarf.exe[0x410001] <+1>:   89 e5 movebp, esp
> infinite-dwarf.exe[0x410003] <+3>:   83 ec 18  subesp, 0x18
> infinite-dwarf.exe[0x410006] <+6>:   8b 45 0c  moveax, dword 
> ptr [ebp + 0xc]
> infinite-dwarf.exe[0x410009] <+9>:   8b 4d 08  movecx, dword 
> ptr [ebp + 0x8]
> infinite-dwarf.exe[0x41000c] <+12>:  c7 45 fc 00 00 00 00  movdword ptr 
> [ebp - 0x4], 0x0
> infinite-dwarf.exe[0x410013] <+19>:  89 45 f8  movdword ptr 
> [ebp - 0x8], eax
> infinite-dwarf.exe[0x410016] <+22>:  89 4d f4  movdword ptr 
> [ebp - 0xc], ecx
> infinite-dwarf.exe`main + 25 at infinite.cpp:6
>5int main(int argc, char **argv) {
>6int n = 0;
>7while (n < 10) {
> infinite-dwarf.exe[0x410019] <+25>:  c7 45 f0 00 00 00 00  movdword ptr 
> [ebp - 0x10], 0x0
> infinite-dwarf.exe`main + 32 at infinite.cpp:7
>6int n = 0;
>7while (n < 10) {
>8std::cout << n << std::endl;
> infinite-dwarf.exe[0x410020] <+32>:  83 7d f0 0a   cmpdword ptr 
> [ebp - 0x10], 0xa
> infinite-dwarf.exe`main + 36 at infinite.cpp:7
>6int n = 0;
>7while (n < 10) {
>8std::cout << n << std::endl;
> infinite-dwarf.exe[0x410024] <+36>:  0f 8d 4a 00 00 00 jge0x410074 
> infinite-dwarf.exe`main + 42 at infinite.cpp:8
>7while (n < 10) {
>8std::cout << n << std::endl;
>9Sleep(1000);
> infinite-dwarf.exe[0x41002a] <+42>:  8b 45 f0  moveax, dword 
> ptr [ebp - 0x10]
> infinite-dwarf.exe`main + 45 at infinite.cpp:8
>7while (n < 10) {
>8std::cout << n << std::endl;
>9Sleep(1000);
> infinite-dwarf.exe[0x41002d] <+45>:  89 e1 movecx, esp
> infinite-dwarf.exe[0x41002f] <+47>:  89 01 movdword ptr 
> [ecx], eax
> infinite-dwarf.exe[0x410031] <+49>:  b9 80 c1 40 00movecx, 
> 0x40c180
> infinite-dwarf.exe[0x410036] <+54>:  e8 55 0a 00 00call   0x410a90
> infinite-dwarf.exe[0x41003b] <+59>:  83 ec 04  subesp, 0x4
> infinite-dwarf.exe`main + 62 at infinite.cpp:8
>7while (n < 10) {
>8std::cout << n << std::endl;
>9Sleep(1000);
> infinite-dwarf.exe[0x41003e] <+62>:  89 e1 movecx, esp
> infinite-dwarf.exe[0x410040] <+64>:  c7 01 50 0d 41 00 movdword ptr 
> [ecx], 0x410d50
> infinite-dwarf.exe[0x410046] <+70>:  89 c1 movecx, eax
> infinite-dwarf.exe[0x410048] <+72>:  e8 e3 0c 00 00call   0x410d30
> infinite-dwarf.exe[0x41004d] <+77>:  83 ec 04  subesp, 0x4
> 
> 
> ; function becomes discontiguous here
> 
> 
> 
> infinite-dwarf.exe`main + 80 at infinite.cpp:9
>8std::cout << n << std::endl;
>9Sleep(1000);
>10   n++;
> infinite-dwarf.exe[0x510050] <+80>:  89 e1 movecx, esp
> infinite-dwarf.exe[0x510052] <+82>:  c7 01 e8 03 00 00 movdword ptr 
> [ecx], 0x3e8
> infinite-dwarf.exe[0x510058] <+88>:  8b 0d 04 93 43 00 movecx, dword 
> ptr [0x439304]
> infinite-dwarf.exe[0x51005e] <+94>:  89 45 ec  movdword ptr 
> [ebp - 0x14], eax
> infinite-dwarf.exe[0x510061] <+97>:  ff d1 call   ecx
> infinite-dwarf.exe[0x510063] <+99>:  83 ec 04  subesp, 0x4
> infinite-dwarf.exe`main + 102 at infinite.cpp:10
>9Sleep(1000);
>10   n++;
>11   }
> infinite-dwarf.exe[0x510066] <+102>: 8b 45 f0  moveax, dword 
> ptr [ebp - 0x10]
> infinite-dwarf.exe[0x510069] <+105>: 83 c0 01  addeax, 0x1
> infinite-dwarf.exe[0x51006c] <+108>: 89 45 f0  movdword ptr 
> [ebp - 0x10], eax
> infinite-dwarf.exe`main + 111 at infinite.cpp:7
>6int n = 0;
>7while (n < 10) {
>8std::cout << n << std::endl;
> infinite-dwarf.exe[0x51006f] <+111>: e9 ac ff ff ffjmp0x410020
> infinite-dwarf.exe[0x510074] <+116>: 31 c0 xoreax, eax
> infinite-dwarf.exe`main + 118 at infinite.cpp:13
>12
>13   return 0;
>14   }
> infinite-dwarf.exe[0x510076] <+118>: 83 c4 18  addesp, 0x18
> infinite-dwarf.exe[0x510079] <+121>: 5dpopebp
> infinite-dwarf.exe[0x51007a] <+122>: c3ret
> 

Re: [lldb-dev] Question about building line tables

[Greg Clayton via lldb-dev]

If the PDB line tables have sizes you could do:

PDBLineEntry curr = pdb->GetLineEntry(n);
PDBLineEntry next = pdb->GetLineEntry(n+1);

line_entries.insert(curr.addr, curr.line, curr.file, false /*is_terminal*/);

if (curr.addr + curr.size != next.addr)
{
// Insert terminal entry for end of curr
line_entries.insert(curr.addr + curr.size, curr.line, curr.file, true 
/*is_terminal*/);
}

Above is pseudo code, but you get the idea...

> On Mar 8, 2016, at 12:56 PM, Zachary Turner  wrote:
> 
> Let's suppose I've got this function (ignore the operands to branch 
> instructions, I disassembled a real function and just manually adjusted 
> addresses on the left side only just to create a contrived example).  
> 
> infinite-dwarf.exe`main at infinite.cpp:5
>4
>5int main(int argc, char **argv) {
>6int n = 0;
> infinite-dwarf.exe`main:
> infinite-dwarf.exe[0x41] <+0>:   55push   ebp
> infinite-dwarf.exe[0x410001] <+1>:   89 e5 movebp, esp
> infinite-dwarf.exe[0x410003] <+3>:   83 ec 18  subesp, 0x18
> infinite-dwarf.exe[0x410006] <+6>:   8b 45 0c  moveax, dword 
> ptr [ebp + 0xc]
> infinite-dwarf.exe[0x410009] <+9>:   8b 4d 08  movecx, dword 
> ptr [ebp + 0x8]
> infinite-dwarf.exe[0x41000c] <+12>:  c7 45 fc 00 00 00 00  movdword ptr 
> [ebp - 0x4], 0x0
> infinite-dwarf.exe[0x410013] <+19>:  89 45 f8  movdword ptr 
> [ebp - 0x8], eax
> infinite-dwarf.exe[0x410016] <+22>:  89 4d f4  movdword ptr 
> [ebp - 0xc], ecx
> infinite-dwarf.exe`main + 25 at infinite.cpp:6
>5int main(int argc, char **argv) {
>6int n = 0;
>7while (n < 10) {
> infinite-dwarf.exe[0x410019] <+25>:  c7 45 f0 00 00 00 00  movdword ptr 
> [ebp - 0x10], 0x0
> infinite-dwarf.exe`main + 32 at infinite.cpp:7
>6int n = 0;
>7while (n < 10) {
>8std::cout << n << std::endl;
> infinite-dwarf.exe[0x410020] <+32>:  83 7d f0 0a   cmpdword ptr 
> [ebp - 0x10], 0xa
> infinite-dwarf.exe`main + 36 at infinite.cpp:7
>6int n = 0;
>7while (n < 10) {
>8std::cout << n << std::endl;
> infinite-dwarf.exe[0x410024] <+36>:  0f 8d 4a 00 00 00 jge0x410074 
> infinite-dwarf.exe`main + 42 at infinite.cpp:8
>7while (n < 10) {
>8std::cout << n << std::endl;
>9Sleep(1000);
> infinite-dwarf.exe[0x41002a] <+42>:  8b 45 f0  moveax, dword 
> ptr [ebp - 0x10]
> infinite-dwarf.exe`main + 45 at infinite.cpp:8
>7while (n < 10) {
>8std::cout << n << std::endl;
>9Sleep(1000);
> infinite-dwarf.exe[0x41002d] <+45>:  89 e1 movecx, esp
> infinite-dwarf.exe[0x41002f] <+47>:  89 01 movdword ptr 
> [ecx], eax
> infinite-dwarf.exe[0x410031] <+49>:  b9 80 c1 40 00movecx, 
> 0x40c180
> infinite-dwarf.exe[0x410036] <+54>:  e8 55 0a 00 00call   0x410a90
> infinite-dwarf.exe[0x41003b] <+59>:  83 ec 04  subesp, 0x4
> infinite-dwarf.exe`main + 62 at infinite.cpp:8
>7while (n < 10) {
>8std::cout << n << std::endl;
>9Sleep(1000);
> infinite-dwarf.exe[0x41003e] <+62>:  89 e1 movecx, esp
> infinite-dwarf.exe[0x410040] <+64>:  c7 01 50 0d 41 00 movdword ptr 
> [ecx], 0x410d50
> infinite-dwarf.exe[0x410046] <+70>:  89 c1 movecx, eax
> infinite-dwarf.exe[0x410048] <+72>:  e8 e3 0c 00 00call   0x410d30
> infinite-dwarf.exe[0x41004d] <+77>:  83 ec 04  subesp, 0x4
> 
> 
> ; function becomes discontiguous here
> 
> 
> 
> infinite-dwarf.exe`main + 80 at infinite.cpp:9
>8std::cout << n << std::endl;
>9Sleep(1000);
>10   n++;
> infinite-dwarf.exe[0x510050] <+80>:  89 e1 movecx, esp
> infinite-dwarf.exe[0x510052] <+82>:  c7 01 e8 03 00 00 movdword ptr 
> [ecx], 0x3e8
> infinite-dwarf.exe[0x510058] <+88>:  8b 0d 04 93 43 00 movecx, dword 
> ptr [0x439304]
> infinite-dwarf.exe[0x51005e] <+94>:  89 45 ec  movdword ptr 
> [ebp - 0x14], eax
> infinite-dwarf.exe[0x510061] <+97>:  ff d1 call   ecx
> infinite-dwarf.exe[0x510063] <+99>:  83 ec 04  subesp, 0x4
> infinite-dwarf.exe`main + 102 at infinite.cpp:10
>9Sleep(1000);
>10   n++;
>11   }
> infinite-dwarf.exe[0x510066] <+102>: 8b 45 f0  moveax, dword 
> ptr [ebp - 0x10]
> infinite-dwarf.exe[0x510069] <+105>: 83 c0 01  addeax, 0x1
> infinite-dwarf.exe[0x51006c] <+108>: 89 45 f0  movdword ptr 
> [ebp - 0x10], eax
> infinite-dwarf.exe`main + 111 at infinite.cpp:7
>6int n = 0;
>7while (n < 10) {
>8std::cout << n << std::endl;
> infinite-dwarf.exe[0x5100

Re: [lldb-dev] How to get the error message while creating an invalid target?

[Greg Clayton via lldb-dev]

The SBDebugger::CreateTarget() call take an "SBError &error" as the last 
argument. The error will contain any error message:

lldb::SBTarget
CreateTarget (const char *filename,
  const char *target_triple,
  const char *platform_name,
  bool add_dependent_modules,
  lldb::SBError& error);



This function is the one that should be used. Any of the "const char *" 
arguments can be NULL. But typically you want to specify at least the filename. 
The triple is only really needed if you are debugging files that have more than 
one architecture or if the file you are debugging doesn't completely specify 
what you want to debug. The triple can be "x86_64" or more specific like 
"x86_64-apple-ios". The platform name only needs to be specified if your 
executable file (ELF file, mach-o file, or other exe format) doesn't have 
enough information inside of it to extract the triple from the object file. ELF 
has very sparse information inside of it to help us identify what platform it 
can/should be used for. You will know if you need to specify the platform if 
LLDB gets it wrong. To see what happens, try things out from the command line:


(lldb) target create /tmp/a.out
(lldb) target list
Current targets:
* target #0: /tmp/a.out ( arch=x86_64-apple-macosx, platform=host )

We see that the "host" platform was auto selected and the architecture was 
extracted from the executable as "x86_64-apple-macosx". 

To see a list of platform names you can do:

(lldb) platform select  
Available completions:
remote-freebsd
remote-linux
remote-netbsd
remote-windows
kalimba
remote-android
remote-ios
remote-macosx
ios-simulator
darwin-kernel
tvos-simulator
watchos-simulator
remote-tvos
remote-watchos
remote-gdb-server

So if you have an iOS binary that was targeting a device (not a simulator), you 
could create your target with:

lldb::SBError error;
lldb::SBTarget target = debugger.CreateTarget("/tmp/a.out", "armv7-apple-ios", 
"remote-ios", false, error);


> On Mar 8, 2016, at 5:22 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Hi,
> 
> In lldb, when I try to "target create [invalid_target]", I got some 
> meaningful error message like:
> error: 'XXX' doesn't contain any 'host' platform architectures: x86_64h, 
> x86_64, i386
> 
> What is the python API to get this from? I tried to check SBTarget.IsValid() 
> and then use SBTarget.GetDescription(eDescriptionLevelVerbose), but that does 
> not return the error message. 
> 
> Thanks
> Jeffrey
> ___
> 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] How to get the error message while creating an invalid target?

[Greg Clayton via lldb-dev]

Yep, this is legacy API that must stay in because we had it in our API waaa 
back when and we never remove API once it has made it into a build and someone 
uses it. We might mark it as deprecated, which we should do to 
CreateTargetWithFileAndArch and the other function, but we never remove it.

Greg Clayton

> On Mar 9, 2016, at 10:53 AM, Jeffrey Tan  wrote:
> 
> Ah, I used CreateTargetWithFileAndArch() and missed this one. Feeling 
> embarrassed... Thank you!
> 
> On Wed, Mar 9, 2016 at 10:10 AM, Greg Clayton  wrote:
> The SBDebugger::CreateTarget() call take an "SBError &error" as the last 
> argument. The error will contain any error message:
> 
> lldb::SBTarget
> CreateTarget (const char *filename,
>   const char *target_triple,
>   const char *platform_name,
>   bool add_dependent_modules,
>   lldb::SBError& error);
> 
> 
> 
> This function is the one that should be used. Any of the "const char *" 
> arguments can be NULL. But typically you want to specify at least the 
> filename. The triple is only really needed if you are debugging files that 
> have more than one architecture or if the file you are debugging doesn't 
> completely specify what you want to debug. The triple can be "x86_64" or more 
> specific like "x86_64-apple-ios". The platform name only needs to be 
> specified if your executable file (ELF file, mach-o file, or other exe 
> format) doesn't have enough information inside of it to extract the triple 
> from the object file. ELF has very sparse information inside of it to help us 
> identify what platform it can/should be used for. You will know if you need 
> to specify the platform if LLDB gets it wrong. To see what happens, try 
> things out from the command line:
> 
> 
> (lldb) target create /tmp/a.out
> (lldb) target list
> Current targets:
> * target #0: /tmp/a.out ( arch=x86_64-apple-macosx, platform=host )
> 
> We see that the "host" platform was auto selected and the architecture was 
> extracted from the executable as "x86_64-apple-macosx".
> 
> To see a list of platform names you can do:
> 
> (lldb) platform select 
> Available completions:
> remote-freebsd
> remote-linux
> remote-netbsd
> remote-windows
> kalimba
> remote-android
> remote-ios
> remote-macosx
> ios-simulator
> darwin-kernel
> tvos-simulator
> watchos-simulator
> remote-tvos
> remote-watchos
> remote-gdb-server
> 
> So if you have an iOS binary that was targeting a device (not a simulator), 
> you could create your target with:
> 
> lldb::SBError error;
> lldb::SBTarget target = debugger.CreateTarget("/tmp/a.out", 
> "armv7-apple-ios", "remote-ios", false, error);
> 
> 
> > On Mar 8, 2016, at 5:22 PM, Jeffrey Tan via lldb-dev 
> >  wrote:
> >
> > Hi,
> >
> > In lldb, when I try to "target create [invalid_target]", I got some 
> > meaningful error message like:
> > error: 'XXX' doesn't contain any 'host' platform architectures: x86_64h, 
> > x86_64, i386
> >
> > What is the python API to get this from? I tried to check 
> > SBTarget.IsValid() and then use 
> > SBTarget.GetDescription(eDescriptionLevelVerbose), but that does not return 
> > the error message.
> >
> > Thanks
> > Jeffrey
> > ___
> > 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] What's the purpose of the TestStarted-XXX and TestFinished-XXX files?

[Greg Clayton via lldb-dev]

I would be happy to see these files go away if no one is using them...

> On Mar 9, 2016, at 2:32 PM, Adrian McCarthy via lldb-dev 
>  wrote:
> 
> The test traces directory tends to accumulate thousands and thousands of 
> TestStarted-XXX and TestFinished-XXX files.  What purpose do they serve?
> 
> I assume it's for trying to figure out why something went wrong.  If you have 
> a TestStarted-123 without a corresponding TestFinished-123, then you can know 
> that a test crashes and by looking inside the file, you can see which test 
> and what the command was.
> 
> If that's the case, then wouldn't it be cleaner to delete the TestStarted 
> file when the test finishes rather than writing a second file?  Then you can 
> simply search for TestStarted files to see the ones that didn't finish 
> successfully without the noise of thousands of others that did.
> 
> I suppose it's also possible that some other process is looking at these 
> files in order to collect statistics.  Is there such a beast and is it 
> valuable?
> 
> Adrian.
> ___
> 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] Better error message for attaching to a process already being debugged

[Greg Clayton via lldb-dev]

Did you follow the instructions and you have made your "lldb_codesign" code 
signing certificate?:

svn cat http://llvm.org/svn/llvm-project/lldb/trunk/docs/code-signing.txt

If you don't do this, your debugserver won't have the ability to debug 
anything. If you don't want to do this, you can remove the "debugserver" binary 
from your LLDB.framework that you built and are running with, and then we will 
fall back to using the one that is installed inside /Applications/Xcode.app as 
that one is Apple code signed.

Greg

> On Mar 9, 2016, at 3:04 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Hi,
> 
> My colleague is trying to use our lldb IDE attaching to app run/build from 
> Xcode which failed. I can reproduce this with lldb console:
> 
> jeffreytan-mbp:$ ps aux | grep iOSApp
> jeffreytan  61816   0.0  0.0  2432772676 s002  S+3:00PM   0:00.00 
> grep iOSApp
> jeffreytan  61806   0.0  0.2  2721120  38600   ??  SXs   3:00PM   0:00.24 
> /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/EF17E202-3981-4DB0-87C9-2A9345C1E713/data/Containers/Bundle/Application/CAEBA7D7-D284-4489-8A53-A88E56F9BB04/iOSAppTest.app/iOSAppTest
> jeffreytan-mbp:$ lldb -p 61806
> (lldb) process attach --pid 61806
> error: attach failed: attach failed: unable to attach
> 
> My theory is:
> 1. Xcode does not have the concept of run without debugger and run under 
> debugger, so it always run app with debugger enabled.(Is this true?)
> 2. And you can't have two native debuggers debugging the same process on 
> Mac(this is true on Windows, is it true for Mac or Linux?)
> 
> If both are true, can we report meaningful message like "inferior is already 
> being debugged" or something similar instead of the generic error message 
> like "attach failed: unable to attach"? 
> 
> Btw: I found I can still use gdb to attach to the process(with a permission 
> elevation dialog pop-up) and see the callstack. How does gdb do that?
> 
> Jeffrey
> ___
> 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] DWARFASTParserClang and DW_TAG_typedef for anonymous structs

[Greg Clayton via lldb-dev]

So we ran into a problem where we had anonymous structs in modules. They have 
no name, so we had no way to say "module A, please give me a struct named... 
nothing in the namespace 'foo'". Obviously this doesn't work, so we always try 
to make sure a typedef doesn't come from a module first, by asking us to get 
the typedef from the DWO file:

type_sp = ParseTypeFromDWO(die, log);

If this fails, it just means we have the typedef in hand. If I compile your 
example I end up with:

0x000b: TAG_compile_unit [1] *
 AT_producer( "Apple LLVM version 8.0.0 (clang-800.0.5.3)" )
 AT_language( DW_LANG_C99 )
 AT_name( "main.c" )
 AT_stmt_list( 0x )
 AT_comp_dir( "/tmp" )
 AT_low_pc( 0x00010f60 )
 AT_high_pc( 0x00010fb0 )

0x002e: TAG_subprogram [2] *
 AT_low_pc( 0x00010f60 )
 AT_high_pc( 0x00010f85 )
 AT_frame_base( rbp )
 AT_name( "myfunc" )
 AT_decl_file( "/private/tmp/main.c" )
 AT_decl_line( 6 )
 AT_prototyped( 0x01 )
 AT_external( 0x01 )

0x0049: TAG_formal_parameter [3]  
 AT_location( fbreg -8 )
 AT_name( "s" )
 AT_decl_file( "/private/tmp/main.c" )
 AT_decl_line( 6 )
 AT_type( {0x008c} ( my_untagged_struct* ) )

0x0057: NULL

0x0058: TAG_subprogram [4] *
 AT_low_pc( 0x00010f90 )
 AT_high_pc( 0x00010fb0 )
 AT_frame_base( rbp )
 AT_name( "main" )
 AT_decl_file( "/private/tmp/main.c" )
 AT_decl_line( 12 )
 AT_type( {0x0085} ( int ) )
 AT_external( 0x01 )

0x0076: TAG_variable [5]  
 AT_location( fbreg -16 )
 AT_name( "s" )
 AT_decl_file( "/private/tmp/main.c" )
 AT_decl_line( 14 )
 AT_type( {0x0091} ( my_untagged_struct ) )

0x0084: NULL

0x0085: TAG_base_type [6]  
 AT_name( "int" )
 AT_encoding( DW_ATE_signed )
 AT_byte_size( 0x04 )

0x008c: TAG_pointer_type [7]  
 AT_type( {0x0091} ( my_untagged_struct ) )

0x0091: TAG_typedef [8]  
 AT_type( {0x009c} ( struct  ) )
 AT_name( "my_untagged_struct" )
 AT_decl_file( "/private/tmp/main.c" )
 AT_decl_line( 4 )

0x009c: TAG_structure_type [9] *
 AT_byte_size( 0x08 )
 AT_decl_file( "/private/tmp/main.c" )
 AT_decl_line( 1 )

0x00a0: TAG_member [10]  
 AT_name( "i" )
 AT_type( {0x0085} ( int ) )
 AT_decl_file( "/private/tmp/main.c" )
 AT_decl_line( 2 )
 AT_data_member_location( +0 )

0x00ae: TAG_member [10]  
 AT_name( "f" )
 AT_type( {0x00bd} ( float ) )
 AT_decl_file( "/private/tmp/main.c" )
 AT_decl_line( 3 )
 AT_data_member_location( +4 )

0x00bc: NULL

0x00bd: TAG_base_type [6]  
 AT_name( "float" )
 AT_encoding( DW_ATE_float )
 AT_byte_size( 0x04 )

0x00c4: NULL


Note that the typedef is at 0x0091, and it is a typedef to 0x009c.  
Also note that the DWARF DIE at 0x009c is a complete definition as it has 
children describing its members and 0x009c doesn't have a 
DW_AT_declaration(1) attribute. Is this how your DWARF looks for your stuff? 
The DWARF you had looked like:

0x005c:   DW_TAG_typedef [6]  
   DW_AT_name( "my_untagged_struct" ) 
   DW_AT_decl_file("/home/luke/main.cpp") 
   DW_AT_decl_line(4)
   DW_AT_type({0x002d})


What did the type at 0x002d look like? Similar to 0x009c in my DWARF I 
presume?

The DWARFASTParserClang class is responsible for making up a clang type in the 
clang::ASTContext for this typedef. What will happen in the code where the flow 
falls through is the we will make a lldb_private::Type that says "I am a 
typedef to type whose user ID is 0x002d (in your example)". A NULL pointer 
should not be returned from the DWARFASTParserClang::ParseTypeFromDWARF() 
function. If it is, please step through and figure out why. I compiled your 
example and did the following:


% lldb a.out 
(lldb) b main
(lldb) r
Process 89808 launched: '/private/tmp/a.out' (x86_64)
Process 89808 stopped
* thread #1: tid = 0xf7473, 0x00010fa3 a.out main + 19, stop reason = 
breakpoint 1.1, q

Re: [lldb-dev] Better error message for attaching to a process already being debugged

[Greg Clayton via lldb-dev]

> On Mar 9, 2016, at 5:40 PM, Jeffrey Tan  wrote:
> 
> Hi Greg, I am using the lldb(/usr/bin/lldb) installed by Xcode not self-built 
> one. For example, I can use lldb to attach to chrome without any problem. And 
> I can see the debugserver it uses is from 
> "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver".
>  Do I still need to sign it?

No, this one is code signed with an Apple certificate which is trusted by the 
system.

> Only the app launched from Xcode IDE can't be attached from this lldb.

Try using "xcrun lldb" instead of /usr/bin/lldb.

> 
> On Wed, Mar 9, 2016 at 3:08 PM, Greg Clayton  wrote:
> Did you follow the instructions and you have made your "lldb_codesign" code 
> signing certificate?:
> 
> svn cat http://llvm.org/svn/llvm-project/lldb/trunk/docs/code-signing.txt
> 
> If you don't do this, your debugserver won't have the ability to debug 
> anything. If you don't want to do this, you can remove the "debugserver" 
> binary from your LLDB.framework that you built and are running with, and then 
> we will fall back to using the one that is installed inside 
> /Applications/Xcode.app as that one is Apple code signed.
> 
> Greg
> 
> > On Mar 9, 2016, at 3:04 PM, Jeffrey Tan via lldb-dev 
> >  wrote:
> >
> > Hi,
> >
> > My colleague is trying to use our lldb IDE attaching to app run/build from 
> > Xcode which failed. I can reproduce this with lldb console:
> >
> > jeffreytan-mbp:$ ps aux | grep iOSApp
> > jeffreytan  61816   0.0  0.0  2432772676 s002  S+3:00PM   
> > 0:00.00 grep iOSApp
> > jeffreytan  61806   0.0  0.2  2721120  38600   ??  SXs   3:00PM   
> > 0:00.24 
> > /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/EF17E202-3981-4DB0-87C9-2A9345C1E713/data/Containers/Bundle/Application/CAEBA7D7-D284-4489-8A53-A88E56F9BB04/iOSAppTest.app/iOSAppTest
> > jeffreytan-mbp:$ lldb -p 61806
> > (lldb) process attach --pid 61806
> > error: attach failed: attach failed: unable to attach
> >
> > My theory is:
> > 1. Xcode does not have the concept of run without debugger and run under 
> > debugger, so it always run app with debugger enabled.(Is this true?)
> > 2. And you can't have two native debuggers debugging the same process on 
> > Mac(this is true on Windows, is it true for Mac or Linux?)
> >
> > If both are true, can we report meaningful message like "inferior is 
> > already being debugged" or something similar instead of the generic error 
> > message like "attach failed: unable to attach"?
> >
> > Btw: I found I can still use gdb to attach to the process(with a permission 
> > elevation dialog pop-up) and see the callstack. How does gdb do that?
> >
> > Jeffrey
> > ___
> > 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] Not able to find process plugin for core file

[Greg Clayton via lldb-dev]

> On Mar 10, 2016, at 4:34 AM, Bhushan Attarde via lldb-dev 
>  wrote:
> 
> Hi All,
>  
> I am working on adding support for MIPS coredump file in LLDB.
>  
> I tried below command:
>  
> (lldb) target create "app_mips.elf" --core "core_mips"
> error: Unable to find process plug-in for core file '/home/battarde/test/ 
> core_mips’
>  
> Currently LLDB is not able to find a Process plugin for MIPS core file. I 
> debugged this and found that while finding the process plugin, 
> "ProcessElfCore::CanDebug" calls "ModuleList::GetSharedModule"
> to create a Module for corefile. But Module constructor in Module.cpp has 
> this:
>  
> // First extract all module specifications from the file using the local
> // file path. If there are no specifications, then don't fill anything in
> ModuleSpecList modules_specs;
> if (ObjectFile::GetModuleSpecifications(module_spec.GetFileSpec(), 0, 0, 
> modules_specs) == 0)
> return;
> 
> The issue here is that the targets like MIPS depends on elf flags to 
> determine the actual architecture but core file doesn't contain any arch 
> information (header.e_flags is 0) so it can't decide the arch contained in 
> core file.
> As no specifications are found, Module constructor takes an early exit 
> leaving its members uninitialized.
>  
> Going further, Module also fails to get the ObjectFile representation as it 
> doesn't contain enough information (Module::m_file, Module::m_arch) required 
> to get ObjectFile.
>  
> So, "ProcessElfCore::CanDebug" returns false and because of this LLDB gives 
> error saying that it is unable to find process plug-in for core file.
>  
> I can make mipsVariantFromElfFlags() to return some default architecture (to 
> ensure we always have valid arch when it can't be decided from elf flags) but 
> this won't always work (core's default arch and executable_elf's arch may not 
> "match" always).
> What could be the proper fix to this issue?

Try specifying a full triple when creating the target:


(lldb) target create --arch=mips32-pc-linux "app_mips.elf" --core "core_mips"

If any ELF file is unable to figure out its file type, it should leave things 
generic so the triple for the core ELF file should be something like: 
"mips-*-*". If that is true, then this should match your more specific triple 
specified in the target of "mips32-pc-linux". 

Try out specifying the triple and let me know how that goes. 

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

Re: [lldb-dev] DWARFASTParserClang and DW_TAG_typedef for anonymous structs

[Greg Clayton via lldb-dev]

Thanks for the example, this is indeed a new regression. It used to work (Xcode 
7.2), but now with top of tree it doesn't. Sean Callanan recently pulled out a 
bunch of work around we used to have in the expression/JIT so that we can avoid 
certain issues that were caused by said work arounds, and those are causing 
problems now. I looked at the old expression parser and it will still making up 
the name _Z6myfuncP3$_0, but it would first try the mangled name, and if it 
didn't find that, then it would fall back to just looking for the demangled 
basename ("myfunc"). We removed this work around because now we are trying to 
be more correct, and that caused this regression. Sean Callanan will take a 
look at this and get a fix for it sometime soon. What is probably happening is 
we are removing the typedef sugar from the function arguments somewhere that we 
shouldn't be (like maybe in the clang::ASTImporter or our 
lldb_private::ClangASTImporter). We should be trying to lookup the mangle name 
"_Z6myfuncP18my_untagged_struct", but somehow when we go to lookup the type we 
lost the my_untagged_struct and are looking for an anonymous struct "$_0" 
instead.

Greg Clayton

> On Mar 10, 2016, at 10:20 AM, Luke Drummond  
> wrote:
> 
> Hi Greg
> 
> First of all thanks for taking the time to help out with this.
> 
> On 10/03/16 00:18, Greg Clayton wrote:
>> So we ran into a problem where we had anonymous structs in modules. They 
>> have no name, so we had no way to say "module A, please give me a struct 
>> named... nothing in the namespace 'foo'". Obviously this doesn't work, so we 
>> always try to make sure a typedef doesn't come from a module first, by 
>> asking us to get the typedef from the DWO file:
>> 
>> type_sp = ParseTypeFromDWO(die, log);
>> 
>> If this fails, it just means we have the typedef in hand. If I compile your 
>> example I end up with:
>> 
>> 0x000b: TAG_compile_unit [1] *
>>  AT_producer( "Apple LLVM version 8.0.0 (clang-800.0.5.3)" )
>>  AT_language( DW_LANG_C99 )
>>  AT_name( "main.c" )
>>  AT_stmt_list( 0x )
>>  AT_comp_dir( "/tmp" )
>>  AT_low_pc( 0x00010f60 )
>>  AT_high_pc( 0x00010fb0 )
>> 
>> 0x002e: TAG_subprogram [2] *
>>  AT_low_pc( 0x00010f60 )
>>  AT_high_pc( 0x00010f85 )
>>  AT_frame_base( rbp )
>>  AT_name( "myfunc" )
>>  AT_decl_file( "/private/tmp/main.c" )
>>  AT_decl_line( 6 )
>>  AT_prototyped( 0x01 )
>>  AT_external( 0x01 )
>> 
>> 0x0049: TAG_formal_parameter [3]
>>  AT_location( fbreg -8 )
>>  AT_name( "s" )
>>  AT_decl_file( "/private/tmp/main.c" )
>>  AT_decl_line( 6 )
>>  AT_type( {0x008c} ( my_untagged_struct* ) )
>> 
>> 0x0057: NULL
>> 
>> 0x0058: TAG_subprogram [4] *
>>  AT_low_pc( 0x00010f90 )
>>  AT_high_pc( 0x00010fb0 )
>>  AT_frame_base( rbp )
>>  AT_name( "main" )
>>  AT_decl_file( "/private/tmp/main.c" )
>>  AT_decl_line( 12 )
>>  AT_type( {0x0085} ( int ) )
>>  AT_external( 0x01 )
>> 
>> 0x0076: TAG_variable [5]
>>  AT_location( fbreg -16 )
>>  AT_name( "s" )
>>  AT_decl_file( "/private/tmp/main.c" )
>>  AT_decl_line( 14 )
>>  AT_type( {0x0091} ( my_untagged_struct ) )
>> 
>> 0x0084: NULL
>> 
>> 0x0085: TAG_base_type [6]
>>  AT_name( "int" )
>>  AT_encoding( DW_ATE_signed )
>>  AT_byte_size( 0x04 )
>> 
>> 0x008c: TAG_pointer_type [7]
>>  AT_type( {0x0091} ( my_untagged_struct ) )
>> 
>> 0x0091: TAG_typedef [8]
>>  AT_type( {0x009c} ( struct  ) )
>>  AT_name( "my_untagged_struct" )
>>  AT_decl_file( "/private/tmp/main.c" )
>>  AT_decl_line( 4 )
>> 
>> 0x009c: TAG_structure_type [9] *
>>  AT_byte_size( 0x08 )
>>  AT_decl_file( "/private/tmp/main.c" )
>>  AT_decl_line( 1 )
>> 
>> 0x00a0: TAG_member [10]
>>  AT_name( "i" )
>>  AT_type( {0x0085} ( int ) )
>>  AT_decl_file( "/private/tmp/main.c" )
>>  AT_decl_line( 2 )
>>  AT_data_member_location( +0 )
>> 
>> 0x00ae: TAG_member [10]
>>  AT_name( "f" )
>>  AT_type( {0x00bd} ( float ) )
>>  AT_decl_file( "/private/tmp/main.c" )
>>  

Re: [lldb-dev] DWARFASTParserClang and DW_TAG_typedef for anonymous structs

[Greg Clayton via lldb-dev]

Please file a bug for this and I will relate it to our internal apple bug that 
tracks this issue.

> On Mar 10, 2016, at 2:03 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> Thanks for the example, this is indeed a new regression. It used to work 
> (Xcode 7.2), but now with top of tree it doesn't. Sean Callanan recently 
> pulled out a bunch of work around we used to have in the expression/JIT so 
> that we can avoid certain issues that were caused by said work arounds, and 
> those are causing problems now. I looked at the old expression parser and it 
> will still making up the name _Z6myfuncP3$_0, but it would first try the 
> mangled name, and if it didn't find that, then it would fall back to just 
> looking for the demangled basename ("myfunc"). We removed this work around 
> because now we are trying to be more correct, and that caused this 
> regression. Sean Callanan will take a look at this and get a fix for it 
> sometime soon. What is probably happening is we are removing the typedef 
> sugar from the function arguments somewhere that we shouldn't be (like maybe 
> in the clang::ASTImporter or our lldb_private::ClangASTImporter). We should 
> be trying to lookup the mangle name "_Z6myfuncP18my_untagged_struct", but 
> somehow when we go to lookup the type we lost the my_untagged_struct and are 
> looking for an anonymous struct "$_0" instead.
> 
> Greg Clayton
> 
>> On Mar 10, 2016, at 10:20 AM, Luke Drummond  
>> wrote:
>> 
>> Hi Greg
>> 
>> First of all thanks for taking the time to help out with this.
>> 
>> On 10/03/16 00:18, Greg Clayton wrote:
>>> So we ran into a problem where we had anonymous structs in modules. They 
>>> have no name, so we had no way to say "module A, please give me a struct 
>>> named... nothing in the namespace 'foo'". Obviously this doesn't work, so 
>>> we always try to make sure a typedef doesn't come from a module first, by 
>>> asking us to get the typedef from the DWO file:
>>> 
>>> type_sp = ParseTypeFromDWO(die, log);
>>> 
>>> If this fails, it just means we have the typedef in hand. If I compile your 
>>> example I end up with:
>>> 
>>> 0x000b: TAG_compile_unit [1] *
>>> AT_producer( "Apple LLVM version 8.0.0 (clang-800.0.5.3)" )
>>> AT_language( DW_LANG_C99 )
>>> AT_name( "main.c" )
>>> AT_stmt_list( 0x )
>>> AT_comp_dir( "/tmp" )
>>> AT_low_pc( 0x00010f60 )
>>> AT_high_pc( 0x00010fb0 )
>>> 
>>> 0x002e: TAG_subprogram [2] *
>>> AT_low_pc( 0x00010f60 )
>>> AT_high_pc( 0x00010f85 )
>>> AT_frame_base( rbp )
>>> AT_name( "myfunc" )
>>> AT_decl_file( "/private/tmp/main.c" )
>>> AT_decl_line( 6 )
>>> AT_prototyped( 0x01 )
>>> AT_external( 0x01 )
>>> 
>>> 0x0049: TAG_formal_parameter [3]
>>> AT_location( fbreg -8 )
>>> AT_name( "s" )
>>> AT_decl_file( "/private/tmp/main.c" )
>>> AT_decl_line( 6 )
>>> AT_type( {0x008c} ( my_untagged_struct* ) )
>>> 
>>> 0x0057: NULL
>>> 
>>> 0x0058: TAG_subprogram [4] *
>>> AT_low_pc( 0x00010f90 )
>>> AT_high_pc( 0x00010fb0 )
>>> AT_frame_base( rbp )
>>> AT_name( "main" )
>>> AT_decl_file( "/private/tmp/main.c" )
>>> AT_decl_line( 12 )
>>> AT_type( {0x0085} ( int ) )
>>> AT_external( 0x01 )
>>> 
>>> 0x0076: TAG_variable [5]
>>> AT_location( fbreg -16 )
>>> AT_name( "s" )
>>> AT_decl_file( "/private/tmp/main.c" )
>>> AT_decl_line( 14 )
>>> AT_type( {0x0091} ( my_untagged_struct ) )
>>> 
>>> 0x0084: NULL
>>> 
>>> 0x0085: TAG_base_type [6]
>>> AT_name( "int" )
>>>   

Re: [lldb-dev] SymbolFile::FindGlobalVariables

[Greg Clayton via lldb-dev]

> On Mar 11, 2016, at 11:02 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> I'm trying to implement this function for PDB.  There are two overloads:
> 
> uint32_t
> FindGlobalVariables (const ConstString &name, const CompilerDeclContext 
> *parent_decl_ctx, bool append, uint32_t max_matches, VariableList& variables)
> 
> uint32_t
> FindGlobalVariables(const RegularExpression& regex, bool append, uint32_t 
> max_matches, VariableList& variables)
> 
> I know how to implement the second overload, but not the first.  What is a 
> CompilerDeclContext?  


It is a declaration context. A variable like "foo::g_int" that is declared like:

namespace foo
{
   int g_int;
}

Has a decl context of "namespace foo". Also a variable like:


namespace foo
{
class bar
{
 struct baz
 {
  void foo();
 };
};
}

The function foo would have a decl context "struct baz". "struct baz" has a 
parent decl context "class bar". "class bar" has a parent decl context 
"namespace foo". "namespace foo" has a parent decl context of "compile unit"


> Some comments in the DWARF implementation of the function seem to imply it's 
> related to namespaces, but there's a lot of strange code that I don't 
> understand.  What is the relationship between a namespace and a symbol file?  
> And why does `DeclContextMatchesThisSymbolFile` contain no code at all that 
> accesses any property of the symbol file?  It just checks if 
> decl_ctx->GetTypeSystem()->GetMinimumLanguage(nullptr) == 
> decl_ctx->GetTypeSystem(), which appears to have nothing to do with any 
> symbol file.

When it comes down to creating types I am going to guess that you will be using 
ClangASTContext to create any types that you hand out. This already has all of 
the needed calls for you to create all of the stuff that you will need. You 
will need to take a look at DWARFASTParserClang and see how it creates types 
using the ClangASTContext.
> 
> What user command or debugger operation results in FindGlobalVariables 
> getting called with this particular overload, and how does it build the 
> CompilerDeclContext?

The SymbolFile subclasses will create decl contexts as needed. In DWARF it uses:

void
SymbolFileDWARF::ParseDeclsForContext (CompilerDeclContext decl_ctx)
{
TypeSystem *type_system = decl_ctx.GetTypeSystem();
DWARFASTParser *ast_parser = type_system->GetDWARFParser();
std::vector decl_ctx_die_list = 
ast_parser->GetDIEForDeclContext(decl_ctx);

for (DWARFDIE decl_ctx_die : decl_ctx_die_list)
for (DWARFDIE decl = decl_ctx_die.GetFirstChild(); decl; decl = 
decl.GetSibling())
ast_parser->GetDeclForUIDFromDWARF(decl);
}

> 
> On another note, why is the decl context stored as void* instead of having an 
> actual wrapper with an abstract interface such as ClangDeclContext / 
> JavaDeclContext, etc that all inherit from LanguageDeclContext, and pass the 
> LanguageDeclContext around instead of a void*?

So three classes: CompilerType, CompilerDecl and CompilerDeclContext all 
contain a "TypeSystem *" which points to a subclass of "TypeSystem". Then each 
different type system will store their native pointer to the thing that 
represents a type, decl and decl context. For ClangASTContext TypeSystem 
produced objects, CompilerType stores a QualType as an opaque pointer gotten 
from a call to "clang::QualType::getAsOpaquePtr()". CompilerDecl stores just 
the "clang::Decl *", and for CompilerDeclContext we store a "clang::DeclContext 
*". Each type system is different. 

SwiftASTContext stores "swift::Type*" in CompilerType, and it doesn't represent 
CompilerDecl or CompilerDeclContext because its expression parser doesn't need 
access to these things.

RenderScript and Go each have their own type systems and can back CompilerType, 
CompilerDecl and CompilerDeclContext as they need to backing them with whatever 
they need. 

Right now CompilerType is the important one since all variable viewing explores 
CompilerType to display the children of a struct/union/class. CompilerDecl and 
CompilerDeclContext will help with expressions and the only thing that needs 
this right now is the clang expression parser for C/C++/ObjC/ObjC++.

When you are asked to parse a type for a variable in your SymbolFilePDB, you 
will be required to make a CompilerType. I would suggest using a 
ClangASTContext as a type system to create your types. You can see how DWARF 
does this in DWARFASTParserClang. You will need to do something very similar. 
If you need to create a class for something like:

namespace A
{
class B
{
};
}

Part of correctly doing so involves you creating a "namespace A" in the 
ClangASTContext (which is a clang::DeclContext). You will specify that the 
translation unit is the decl context for "namespace A" when you create the 
namespace. When you create the "class B", you will need to specify that the 
context that is is created in is the "namespace A" from the ClangASTContext. 
These 

Re: [lldb-dev] SymbolFile::FindGlobalVariables

[Greg Clayton via lldb-dev]

> 
> Also why does the lldb_private::Variable() class take a DWARFExpression to 
> its constructor?  Seems like this is wrong in the face of non-DWARF debug 
> information.

They are powerful enough to handle any variable location. More powerful than 
any other format I have seen. You have two choices:

- make a new lldb_private::Location class and have DWARFExpression implement 
the pure virtuals you need
- convert PDB locations into DWARF

Personally the second sounds easier as the DWARF expressions are well 
documented and they are easy to construct. If you have the spec for the PDB 
locations and can point me at this, I can take a look to see how well things 
would map.

Variables that are in registers use a DWARF location expression like:

DW_OP_reg12

that means the value is register number 12.

DW_OP_addr(0x1) means the value is a global variable whose value lives at 
"file address 0x1 inside of the module from which is originates". We 
translate the file address into a load address if we are running and if that 
resolves to a load address, we can read the variable value.

DW_OP_fbreg32(32) means the value is 32 bytes off of register 32.

So the locations expression are often this simple: in a register, in .data at a 
file address, or on the stack. So depending on how complex locations are in 
PDB, it might be easier to just create a simple DWARF expression and be done 
with 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] SymbolFile::FindGlobalVariables

[Greg Clayton via lldb-dev]

See my other email. You can abstract this, but it doesn't seem worth it unless 
PDB has some really powerful way to express variable locations?

> On Mar 11, 2016, at 11:39 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Can we abstract this somehow?  Converting all my debug info to DWARF seems 
> like a non-starter, as it doesn't look like you can just do it partially, you 
> have to go all the way (just based on glancing at the DWARFExpression header 
> file)
> 
> On Fri, Mar 11, 2016 at 11:38 AM Jim Ingham  wrote:
> lldb uses DWARF expressions internally as a convenient language to represent 
> locations of values.  We had to pick some representation, and the DWARF 
> expression was powerful enough for our purposes, meant we didn't have to 
> reinvent something that already existed, and had the added benefit that if 
> you did your DWARF then you don't have to transcode.
> 
> Jim
> 
> > On Mar 11, 2016, at 11:32 AM, Zachary Turner via lldb-dev 
> >  wrote:
> >
> > Also why does the lldb_private::Variable() class take a DWARFExpression to 
> > its constructor?  Seems like this is wrong in the face of non-DWARF debug 
> > information.
> >
> > On Fri, Mar 11, 2016 at 11:02 AM Zachary Turner  wrote:
> > I'm trying to implement this function for PDB.  There are two overloads:
> >
> > uint32_t
> > FindGlobalVariables (const ConstString &name, const CompilerDeclContext 
> > *parent_decl_ctx, bool append, uint32_t max_matches, VariableList& 
> > variables)
> >
> > uint32_t
> > FindGlobalVariables(const RegularExpression& regex, bool append, uint32_t 
> > max_matches, VariableList& variables)
> >
> > I know how to implement the second overload, but not the first.  What is a 
> > CompilerDeclContext?  Some comments in the DWARF implementation of the 
> > function seem to imply it's related to namespaces, but there's a lot of 
> > strange code that I don't understand.  What is the relationship between a 
> > namespace and a symbol file?  And why does 
> > `DeclContextMatchesThisSymbolFile` contain no code at all that accesses any 
> > property of the symbol file?  It just checks if 
> > decl_ctx->GetTypeSystem()->GetMinimumLanguage(nullptr) == 
> > decl_ctx->GetTypeSystem(), which appears to have nothing to do with any 
> > symbol file.
> >
> > What user command or debugger operation results in FindGlobalVariables 
> > getting called with this particular overload, and how does it build the 
> > CompilerDeclContext?
> >
> > On another note, why is the decl context stored as void* instead of having 
> > an actual wrapper with an abstract interface such as ClangDeclContext / 
> > JavaDeclContext, etc that all inherit from LanguageDeclContext, and pass 
> > the LanguageDeclContext around instead of a void*?
> > ___
> > 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] SymbolFile::FindGlobalVariables

[Greg Clayton via lldb-dev]

Feel free to abstract if you need to. The page you sent me to has _very_ simple 
locations that would convert to DWARF expressions very easily. Probably less 
that a hundred lines of code.

If you need to abstract, making a lldb_private::Location class that 
DWARFExpression would implement the needed pure virtuals. Then each things that 
contains DWARFExpression would now contain a lldb_private::LocationSP which 
would be a shared pointer to a lldb_private::Location. DWARFExpression has 
grown over the years to contain a bunch of evaluate variants.

Just know that LLDB lazily parses things. We don't say "convert the entire PDB 
into the internal LLDB format now!". We say "get the line table for this one 
compile unit". Find the function for address "0x123000" and parse it. Later we 
will ask to get the function type and its args. Later, if we ever need to, we 
will lazily parse the blocks in the function. Nothing is parsed in full.

Let me know what you want to do. Abstraction is great, but comes at a cost of 
breaking things when our tests don't cover everything, so that is a worry on my 
end with any large changes...


> On Mar 11, 2016, at 11:47 AM, Zachary Turner  wrote:
> 
> The only "spec" is the API that allows you to access the info.  There's no 
> spec of the bit format.  This is probably all you are actually looking for 
> though:
> 
> The problem isn't necessarily that one is more pwoerful than the other, it's 
> just that PDBs can get huge (on the order of gigabytes), and converting 
> between formats is an unnecessary step that a) will be slow to do the 
> conversion, b) might not map 1 to 1 between the formats, and c) it' already 
> trivial (on the order of a few lines of code) to just query the PDB for 
> everything you need.
> 
> So we're talking about potentially thousands of lines of code to do something 
> that would take about 10 (as well as being more efficient) with a proper 
> abstraction.
> 
> On Fri, Mar 11, 2016 at 11:43 AM Greg Clayton  wrote:
> See my other email. You can abstract this, but it doesn't seem worth it 
> unless PDB has some really powerful way to express variable locations?
> 
> > On Mar 11, 2016, at 11:39 AM, Zachary Turner via lldb-dev 
> >  wrote:
> >
> > Can we abstract this somehow?  Converting all my debug info to DWARF seems 
> > like a non-starter, as it doesn't look like you can just do it partially, 
> > you have to go all the way (just based on glancing at the DWARFExpression 
> > header file)
> >
> > On Fri, Mar 11, 2016 at 11:38 AM Jim Ingham  wrote:
> > lldb uses DWARF expressions internally as a convenient language to 
> > represent locations of values.  We had to pick some representation, and the 
> > DWARF expression was powerful enough for our purposes, meant we didn't have 
> > to reinvent something that already existed, and had the added benefit that 
> > if you did your DWARF then you don't have to transcode.
> >
> > Jim
> >
> > > On Mar 11, 2016, at 11:32 AM, Zachary Turner via lldb-dev 
> > >  wrote:
> > >
> > > Also why does the lldb_private::Variable() class take a DWARFExpression 
> > > to its constructor?  Seems like this is wrong in the face of non-DWARF 
> > > debug information.
> > >
> > > On Fri, Mar 11, 2016 at 11:02 AM Zachary Turner  
> > > wrote:
> > > I'm trying to implement this function for PDB.  There are two overloads:
> > >
> > > uint32_t
> > > FindGlobalVariables (const ConstString &name, const CompilerDeclContext 
> > > *parent_decl_ctx, bool append, uint32_t max_matches, VariableList& 
> > > variables)
> > >
> > > uint32_t
> > > FindGlobalVariables(const RegularExpression& regex, bool append, uint32_t 
> > > max_matches, VariableList& variables)
> > >
> > > I know how to implement the second overload, but not the first.  What is 
> > > a CompilerDeclContext?  Some comments in the DWARF implementation of the 
> > > function seem to imply it's related to namespaces, but there's a lot of 
> > > strange code that I don't understand.  What is the relationship between a 
> > > namespace and a symbol file?  And why does 
> > > `DeclContextMatchesThisSymbolFile` contain no code at all that accesses 
> > > any property of the symbol file?  It just checks if 
> > > decl_ctx->GetTypeSystem()->GetMinimumLanguage(nullptr) == 
> > > decl_ctx->GetTypeSystem(), which appears to have nothing to do with any 
> > > symbol file.
> > >
> > > What user command or debugger operation results in FindGlobalVariables 
> > > getting called with this particular overload, and how does it build the 
> > > CompilerDeclContext?
> > >
> > > On another note, why is the decl context stored as void* instead of 
> > > having an actual wrapper with an abstract interface such as 
> > > ClangDeclContext / JavaDeclContext, etc that all inherit from 
> > > LanguageDeclContext, and pass the LanguageDeclContext around instead of a 
> > > void*?
> > > ___
> > > lldb-dev mailing list
> > > lldb-dev@lists.llvm.org
> > > http:

Re: [lldb-dev] SymbolFile::FindGlobalVariables

[Greg Clayton via lldb-dev]

> On Mar 11, 2016, at 1:02 PM, Zachary Turner  wrote:
> 
> How large of a change do you think it would be to abstract out the location 
> information for the variable?  As far as I can tell, our uses of this 
> DWARFExpression on Variables are very limited:
> 
> 1. In ValueObjectVariable::UpdateValue and 
> ClangExpressionDeclMap::GetVariableValue, if the location is a constant 
> value, it refers to a a host address, we just read the value out as a number.
> 2. In EntityVariable::Materialize(), we check whether it is valid.
> 3. In SymbolFileDWARF, we "evaluate" the expression.

Leave this one alone, don't abstract it since it is DWARF native.

> 4. In a few places, we check whether an input address matches the location 
> specified.
> 5. We dump the location to stdout in a few places.
> 
> Everything else could just as easily be private methods, because that's all 
> that public users of DWARFExpression actually use.

Sounds like it won't be too bad.
> 
> This seems like an easy abstraction to create.  #3 is irrelevant because that 
> code is in SymbolFileDWARF, it could downcast from Location to DWARFLocation. 
>  #1, 2, 4, and 5 could easily be implemented directly against a PDB.
> 
> While I haven't tried to actually *do* either approach yet, I like the idea 
> of creating the abstraction because it provides the native / most optimized 
> debugging experience no matter what you're using.  For example, I can easily 
> imagine a scenario where I have to keep the PDB open in memory to query some 
> types of information, but I have to do a conversion of location information 
> for Variables, and the memory usage becomes unacceptable because everything 
> is memory twice (even though it's lazily evaluated, the memory usage would 
> double over time).

You will abstract the location only and that is fine. For everything else we do 
have lldb classes that will need to be created (compile units, functions, 
blocks, variables). Types are done via the TypeSystem subclasses so you will 
need convert all types there. So feel free to abstract the DWARFExpression for 
variable locations only.

I have no problem with the abstraction if you think it is needed. I personally 
think it will be much more work, but I won't be doing it so I don't mind.

Greg

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