[lldb-dev] Inquiry about Load Address

2016-03-08 Thread Ravitheja Addepally via lldb-dev 
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 ? secondly Can
we obtain the dumps of the loaded Elf 's like in the remote case
transporting them from the target to the host ?


BR,
A Ravi Theja
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Inquiry about Load Address

2016-03-08 Thread Pavel Labath via lldb-dev 
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] [Bug 26875] New: LLDB GUI segfaults when selecting a particular stack frame

2016-03-08 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=26875

Bug ID: 26875
   Summary: LLDB GUI segfaults when selecting a particular stack
frame
   Product: lldb
   Version: 3.8
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: kknb1...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 16003
  --> https://llvm.org/bugs/attachment.cgi?id=16003&action=edit
Source file of a program that causes a crash in LLDB

I've found I can consistently make the LLDB GUI crash with a particular series
of steps.  A simple source file is attached with instructions in the comments.

Basically, compile the file and start the program in LLDB; continue to a point
where all the threads have started (e.g. before the notify_all); open the gui
and select frame #11 of any of threads #2-#6. LLDB crashes.
This definitely happens on Mac OS X El Capitan with lldb-340.4.119.1 (which
ships with Xcode 7.2.1) as well as the LLDB head as at 08/Mar/16. All line
numbers here refer to the code as at 08/Mar/16.

This is unrelated to bug 26842 (https://llvm.org/bugs/show_bug.cgi?id=26842),
applying that patch has no effect.

The stack trace says the crash is in libncurses, however I'm fairly sure it's
because of memory corruption before hand. The corruption comes when querying
the frame variables to populate the "Variables" window, and it's one variable
in particular - the first one "void * _vp" in frame 11 which is the function
argument.

** To show it's when populating the Variables window: **
Before the crash, attach another debugger to the original lldb with the
following breakpoint (should be on the "if (value_sp)" line):

breakpoint set -f IOHandler.cpp -l 3922 -N skipVarAdd
breakpoint command add skipVarAdd
expression value_sp=nullptr
continue
DONE

This stops any variables being added to the window and there is no crash. You
can also optionally add "--condition i==0" and only enable it before going from
frame 10 to frame 11 to show that it's the first variable in frame 11.

** To show it's a memory corruption unrelated to ncurses **
Again, in a second debugger attached to the first (line 3933 should be "
SetValues(local_values);"):

breakpoint set -f IOHandler.cpp -l 3933 -N clearVars
breakpoint command add clearVars
expression class ValueObjectList $emptyList
expression local_values=$emptyList
continue
DONE

This empties the local list *before* being added to anything that is persisted
beyond the current function. The crash still happens.

It's possible to investigate this further, but I modified the code because I
couldn't figure out how to do it with breakpoints. Just having line 3924
"value_sp->GetSyntheticValue();" is enough to cause the crash (comment out the
"local_value.Append" lines); but also skipping that and adding just value_sp
causes a crash (comment out everything except line 3928
"local_values.Append(value_sp);"). So just using value_sp in any way seems to
be an issue.

** To show it's a problem with the dynamic value **
Again in a second debugger (line should be "if (dynamic_sp)"):

breakpoint set -f StackFrame.cpp -l 1308 -N refuseDynamic
breakpoint command add refuseDynamic
expression dynamic_sp=nullptr
continue
DONE

This makes the gui never use the dynamic value, and everything runs fine.

** To show it's probably(?) a GUI initialisation problem **
Selecting one of the problem frames in any of the threads *before* starting the
gui allows the program to run fine. The frame doesn't even need to be active
when the gui starts, just selected at some point before hand.  E.g. in original
debugger attached to executable

breakpoint set --file main.cpp --line 64
process launch
thread select 2
frame select 11
thread select 1
gui

Then navigate to frame 11 as before and there are no problems. Even navigating
to frame 11 of the other threads (3-6) is fine.

I've tried stepping through the gui initialisation with and without a manual
"frame select 11" and I can't find any notable differences.  I've also tried
stepping through the manual "frame select 11" to see what it does differently
and can't find anything there either.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Inquiry about Load Address

2016-03-08 Thread Ravitheja Addepally via lldb-dev 
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

Re: [lldb-dev] FYI: a python crash running tests

2016-03-08 Thread Adrian McCarthy via lldb-dev 
Did you ever push a fix?  I'm still seeing this problem, even after a fresh
sync.

I'm happy to take a look at it today if you don't already have a fix.

On Thu, Mar 3, 2016 at 10:18 AM, Ted Woodward 
wrote:

> I think I see the problem; I’ll push up a fix.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* Zachary Turner [mailto:ztur...@google.com]
> *Sent:* Thursday, March 03, 2016 11:54 AM
> *To:* Adrian McCarthy; LLDB; Ted Woodward
> *Subject:* Re: FYI: a python crash running tests
>
>
>
> Hi Ted, any chance this is your recent change? I know you had some changes
> in this file recently
>
> On Wed, Mar 2, 2016 at 4:46 PM Adrian McCarthy 
> wrote:
>
> Running ninja check-lldb now has one crash in a Python process, due to
> deferencing a null pointer in IRExecutionUnit.cpp:  candidate_sc.symbol is
> null, which leads to a call with a null this pointer.
>
>
>
> However, the Test Result Summary shows no problems:  0 failures, errors,
> exceptional exits, and timeouts.
>
>
>
> I would try to debug it, but I'm about to head out.
>
>
>
> Adrian.
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] FYI: a python crash running tests

2016-03-08 Thread Ted Woodward via lldb-dev 
Yes, it’s up for review. Please see http://reviews.llvm.org/D17860 .

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Adrian McCarthy [mailto:amcca...@google.com] 
Sent: Tuesday, March 08, 2016 11:34 AM
To: Ted Woodward
Cc: Zachary Turner; LLDB
Subject: Re: FYI: a python crash running tests

 

Did you ever push a fix?  I'm still seeing this problem, even after a fresh 
sync.

 

I'm happy to take a look at it today if you don't already have a fix.

 

On Thu, Mar 3, 2016 at 10:18 AM, Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

I think I see the problem; I’ll push up a fix.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Zachary Turner [mailto:ztur...@google.com  ] 
Sent: Thursday, March 03, 2016 11:54 AM
To: Adrian McCarthy; LLDB; Ted Woodward
Subject: Re: FYI: a python crash running tests

 

Hi Ted, any chance this is your recent change? I know you had some changes in 
this file recently

On Wed, Mar 2, 2016 at 4:46 PM Adrian McCarthy mailto:amcca...@google.com> > wrote:

Running ninja check-lldb now has one crash in a Python process, due to 
deferencing a null pointer in IRExecutionUnit.cpp:  candidate_sc.symbol is 
null, which leads to a call with a null this pointer.

 

However, the Test Result Summary shows no problems:  0 failures, errors, 
exceptional exits, and timeouts.

 

I would try to debug it, but I'm about to head out.

 

Adrian.

 

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

[lldb-dev] LLVM 3.8 Release

2016-03-08 Thread Hans Wennborg via lldb-dev 
It is my pleasure to announce that LLVM 3.8.0 is now available!

Get it here: http://www.llvm.org/releases/download.html#3.8.0

This release contains the work of the LLVM community over the past six
months: deprecated autoconf build, shrink-wrapping on by default,
overhauled MSVC-compatible exception handling, updated Kaleidoscope
tutorial, emutls, OpenMP supported by default, as well as improved
optimizations, many bug fixes, and more.

Release notes for more details:
http://llvm.org/releases/3.8.0/docs/ReleaseNotes.html
http://llvm.org/releases/3.8.0/tools/clang/docs/ReleaseNotes.html

Huge thanks to everyone who helped with testing, bug fixing,
packaging, and getting the release into a good state!

Special thanks to the volunteer release builders and testers, without
whom there would be no releases: Dimitry Andric, Brian Cain, Ismail
Donmez, Renato Golin, Sylvestre Ledru, Elias Pipping, Ben Pope, Daniel
Sanders, and Nikola Smiljanic!

If you have any questions or comments about the release, please
contact the community on the mailing lists. Onward to 3.9!

 - Hans

(LLVM 3.7.1 Release Announcement:
http://lists.llvm.org/pipermail/llvm-announce/2016-January/66.html)
___
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?

2016-03-08 Thread 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] How to set source line breakpoint using BreakpointCreateByLocation?

2016-03-08 Thread Jeffrey Tan via lldb-dev 
Thanks for the info. I will use a solution similar to that.

Jeffrey

On Tue, Mar 8, 2016 at 10:41 AM, Greg Clayton  wrote:

>
> > 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
> (./

Re: [lldb-dev] Inquiry about Load Address

2016-03-08 Thread 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

2016-03-08 Thread Zachary Turner via lldb-dev 
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


About halfway down, the addresses suddenly increase by 0x10.  So the
compiler decided that for some strange reason while unrolling the loop it
was just going to start placing code somewhere else entirely.  Am I correct
in saying that 0x410050 should be a terminal entry in this example?

On

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

2016-03-08 Thread 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

2016-03-08 Thread 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] Question about building line tables

2016-03-08 Thread Zachary Turner via lldb-dev 
Yea, I already whipped up some changes locally that do almost exactly that.

On Tue, Mar 8, 2016 at 3:17 PM Greg Clayton  wrote:

> 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 jge
> 0x410074
> > 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

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

2016-03-08 Thread Jeffrey Tan via lldb-dev 
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