Re: [lldb-dev] [Release-testers] [3.8 Release] 'final' has been tagged

[Brian Cain via lldb-dev]

CentOS 6 uploaded and tested.

05141a39af0998770e4bf1953980a10f69aca450
 clang+llvm-3.8.0-linux-x86_64-centos6.tar.xz


On Wed, Mar 2, 2016 at 6:33 PM, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Dear testers,
>
> My list of blockers is empty, and there were no new problems
> discovered with rc3, so I have gone ahead and tagged 3.8.0-final [1].
>
> Please build the final binaries and upload to the sftp.
>
> For others following along: yes, this means 3.8.0 is complete, but it
> takes a couple of days to get the source and binary tarballs built. I
> will send the release announcement when everything's ready.
>
> Many thanks for all your work!
> Hans
>
>  [1].
> http://lists.llvm.org/pipermail/llvm-branch-commits/2016-March/009883.html
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>



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

Re: [lldb-dev] [3.8 Release] 'final' has been tagged

[Renato Golin via lldb-dev]

Apologies for the delay, ARM and AArch64 tested and uploaded!

--renato

On 3 March 2016 at 07:33, Hans Wennborg via lldb-dev
 wrote:
> Dear testers,
>
> My list of blockers is empty, and there were no new problems
> discovered with rc3, so I have gone ahead and tagged 3.8.0-final [1].
>
> Please build the final binaries and upload to the sftp.
>
> For others following along: yes, this means 3.8.0 is complete, but it
> takes a couple of days to get the source and binary tarballs built. I
> will send the release announcement when everything's ready.
>
> Many thanks for all your work!
> Hans
>
>  [1]. 
> http://lists.llvm.org/pipermail/llvm-branch-commits/2016-March/009883.html
> ___
> 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 set source line breakpoint using BreakpointCreateByLocation?

[Jeffrey Tan via lldb-dev]

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.

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?

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

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?

[Jeffrey Tan via lldb-dev]

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? And it will fail to bind the breakpoint if can't
find the resolved file path?

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"

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 think I am a bit vague on how source
breakpoint is supposed to work. What is the algorithm to successfully bind
breakpoint here?

Jeffrey



On Mon, Mar 7, 2016 at 11:07 AM, Greg Clayton  wrote:

> 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 =
> '.

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

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

[Zachary Turner via lldb-dev]

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.

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?

On Mon, Mar 7, 2016 at 3:13 PM Greg Clayton  wrote:

>
> > On Mar 7, 2016, at 3:07 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> 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]

> 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

[lldb-dev] Question about building line tables

[Zachary Turner via lldb-dev]

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

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?

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

[John Lindal via lldb-dev]

I was planning to take a stab at writing documentation, since I just
finished my own C++ app on top of lldb.  (Code Medic)

Attached is my attempt to add docs to SBAddress.  Am I on the right track?
If so, I'll tackle additional files.

Thanks,
John

On Mon, Mar 7, 2016 at 10:56 AM, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
> > On Mar 4, 2016, at 8:08 AM, Paul Peet via lldb-dev <
> lldb-dev@lists.llvm.org> 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::en

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] 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] [3.8 Release] 'final' has been tagged

[Hans Wennborg via lldb-dev]

On Wed, Mar 2, 2016 at 4:33 PM, Hans Wennborg  wrote:
> Please build the final binaries and upload to the sftp.

Mac and Windows uploaded (sha1sum):
8d1f41aee5f3b29f14db90141430faee5e0d7723
clang+llvm-3.8.0-x86_64-apple-darwin.tar.xz
f30de7ee8006dc779064202bcc345c418c1ac249  LLVM-3.8.0-win32.exe
325cadbcbb45649750434906b229e5f1e6438231  LLVM-3.8.0-win64.exe

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

Re: [lldb-dev] [Release-testers] [3.8 Release] 'final' has been tagged

[Daniel Sanders via lldb-dev]

> -Original Message-
> From: Daniel Sanders
> Sent: 06 March 2016 16:57
> To: Hans Wennborg; Release-testers
> Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev
> Subject: RE: [Release-testers] [3.8 Release] 'final' has been tagged
> 
> Uploaded the following:
> 3d6cb2afdf6d984a087a60188bb41bbe3a8261bb  clang+llvm-3.8.0-mipsel-
> linux-gnu.tar.xz
> b4b3ef9231e8a686901f4078f3fe5534900f2a54  clang+llvm-3.8.0-mips-linux-
> gnu.tar.xz
> 95fd207d3aa3be42b27aa93d9c5c00f18508800f  clang+llvm-3.8.0-x86_64-linux-
> gnu-debian8.tar.xz
> 
> The cross-compilation tests from x86_64 to mips are still running but all 
> other
> tests have been re-run without regressions. In particular, the problems I had
> with the mipsel testing during rc3 have been resolved now that multilib
> support has been removed from that machine again.

The cross compilation tests have just finished with no regressions. 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev