[lldb-dev] [Bug 20406] Can't build lldb 3.4.2 on OS X 10.8.5

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=20406

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lab...@google.com
 Resolution|--- |WORKSFORME

--- Comment #2 from lab...@google.com ---
Should work now.

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

[lldb-dev] [Bug 16172] Continue after process interrupt does not work correctly

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=16172

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lab...@google.com
 Resolution|--- |FIXED

--- Comment #1 from lab...@google.com ---
This should be working now.

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

[lldb-dev] [Bug 15039] lldb.SBProcess.GetSTDOUT() returns empty string instead of inferior output

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=15039

lab...@google.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||lab...@google.com
 Resolution|--- |FIXED

--- Comment #10 from lab...@google.com ---
I think this is fixed now.

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

[lldb-dev] [Bug 24976] Data from SBProcess::PutSTDIN appears in SBProcess::GetSTDOUT

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=24976

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from lab...@google.com ---
I'm gonna call this "working as intended".

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

[lldb-dev] [Bug 15989] Unable to allocate memory after inferior crash and step

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=15989

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lab...@google.com
 Resolution|--- |WONTFIX

--- Comment #6 from lab...@google.com ---
Currently on linux, the inferior will exit if you hit "next" after a "crash"
(== SEGV). I'll call this working as intended, since "next" is a valid way of
handing control to the SEGV handler, if the application has one.

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

[lldb-dev] [Bug 17237] Automated tests are missing for ELF core file support

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=17237

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lab...@google.com
 Resolution|--- |FIXED

--- Comment #2 from lab...@google.com ---
We already have windows minidump- and linux elf core file-tests checked in. I
would encourage other architectures to check-in small core files as well, but
in general, I'd call this fixed.

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

[lldb-dev] [Bug 22252] llgs tests should not write their log files in-tree

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=22252

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lab...@google.com
 Resolution|--- |FIXED

--- Comment #1 from lab...@google.com ---
I believe this was fixed as well, unless there is some windows-specific
strangeness going on..

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

[lldb-dev] [Bug 27652] Tests with syntax errors don't get flagged as erroneous

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=27652

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from lab...@google.com ---
I think this was fixed by r269489.

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

[lldb-dev] [Bug 28041] New: Tab completion adds backslashes to function names, which causes them not to match

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=28041

Bug ID: 28041
   Summary: Tab completion adds backslashes to function names,
which causes them not to match
   Product: lldb
   Version: 3.6
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: chris+l...@qwirx.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

(lldb) b BackupStoreException::BackupStoreException results in:

(lldb) b BackupStoreException::BackupStoreException(unsigned\ int,\
std::__1::basic_string\ const&) 
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.

However, the function does exist:

(lldb) b BackupStoreException::BackupStoreException
 
Breakpoint 2: 2 locations.

I think that the inserted backslashes are the problem. If I remove them,
setting the breakpoint works:

(lldb) b BackupStoreException::BackupStoreException(unsigned int,
std::__1::basic_string const&)
Breakpoint 3: 2 locations.

-- 
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] Structure variable names

[Jiten Thakkar via lldb-dev]

Thanks Greg and Duane, I will try these things and comeback if I have further 
questions.

-Jiten
> On Jun 7, 2016, at 12:28 PM, du...@duaneellis.com wrote:
> 
> You need to understand the DWARF (debug info)
> 
> Try this:
> 
> Create a *SIMPLE* C file - with a simple structure
> Do *not* "#include" any file - make your file 100% standalone.
> (later you can get more complicated, you want a simple translation unit)
> 
> Do the following with both GCC and LLVM
> 
> Compile this file using only the "-c -S"  options. (this produces an assembly 
> listing)
> 
> Next, add the "-g" option thus:  "-c -S -g" - look at the difference.
> Try other variants of the "-g" (see the man pages)
> 
> Look over the .S file output - this should give you a good description of the 
> dwarf info.
> 
> Add things - this will get you started.  Then - start reading about DWARF 
> records and and then start spelunking (cave exploring) through out the code 
> base - both in LLVM and in GDB - compare and contrast.
> 
> Find some function - in the bowels of GDB and/or LLVM and set a breakpoint - 
> use GDB to DEBUG GDB 
> or LLVM to Debug LLVM what ever combination you like.
> 
> A good example would be the "print variable" operation, then step through the 
> code and examine the available variables and the dwarf debug data structures 
> "in-situ" with actual data present.  Also disable the optimizer, and turn on 
> all debugging. This means building your own version of GDB and/or LLVM 
> 
> -Duane.
> 
>  Original Message 
> Subject: [lldb-dev] Structure variable names
> From: Jiten Thakkar via lldb-dev  >
> Date: Tue, June 07, 2016 9:56 am
> To: lldb-dev@lists.llvm.org 
> 
> Hi All,
> I am working on a project as part of my graduate study which uses LLVM.
> I am new to LLVM and lldb to be particular.
> My goal is to get names of the parameters to functions. If the parameter is a 
> variable in a structure, it is represented as an offset in the structure.
> I want to get the names of all those parameters. I assume that debug info 
> should provide this but so far I am unable to find any documentation 
> regarding which would describe how to do it. 
> Is there a way to do this using debug info? Is this even possible?
> Please let me know if any of this is confusing and I will try to describe it 
> in detail.
> 
> Thanks,
> Jiten
> ___
> 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] [cfe-dev] [llvm-dev] GitHub anyone?

[Chris Lattner via lldb-dev]

On Jun 6, 2016, at 10:07 AM, James Y Knight via cfe-dev 
 wrote:
> +1 to that. I would strongly suggest that we continue to commit to master 
> first, like we've always done in llvm.
> 
More generally, I suggest that we keep a discussion about moving hosting and 
svn->git to *just* those topics.  Any changes of workflow should be deferred 
until after and if these changes happen.

-Chris


> 
> On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" 
> > wrote:
> On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote:
> > My only hesitation with this is that this requires use of cherry-pick,
> > which is not idea.  The way most git repositories work is to put
> > everything that should go into a release branch in the release branch
> > *first* and then merge the release branch to master, ensuring that
> > everything going out in a release will make it into the next release.
> > This is how the gitflow workflow works, for example.
> 
> The model of "commit to oldest first" is IMO one of the most stupid
> concepts I have ever seen in git "workflows". It is contrary to the way
> software development works and essentially just a bad workaround for
> broken cherry picks. I've seen more than one project starting to use
> this model due to advocacy after deciding to use git, stumble around
> with it for a release or two and then going back to a normal release
> management approach. Even the argument you have presented here does not
> make sense to me. Just because a change has been committed to a release
> branch, doesn't mean it won't get replaced later.
> 
> Joerg
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev 
> 
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

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

Re: [lldb-dev] Structure variable names

[via lldb-dev]

You need to understand the DWARF (debug info)Try this:Create a *SIMPLE* C file - with a simple structureDo *not* "#include" any file - make your file 100% standalone.(later you can get more complicated, you want a simple translation unit)Do the following with both GCC and LLVMCompile this file using only the "-c -S"  options. (this produces an assembly listing)Next, add the "-g" option thus:  "-c -S -g" - look at the difference.Try other variants of the "-g" (see the man pages)Look over the .S file output - this should give you a good description of the dwarf info.Add things - this will get you started.  Then - start reading about DWARF records and and then start spelunking (cave exploring) through out the code base - both in LLVM and in GDB - compare and contrast.Find some function - in the bowels of GDB and/or LLVM and set a breakpoint - use GDB to DEBUG GDB or LLVM to Debug LLVM what ever combination you like.A good example would be the "print variable" operation, then step through the code and examine the available variables and the dwarf debug data structures "in-situ" with actual data present.  Also disable the optimizer, and turn on all debugging. This means building your own version of GDB and/or LLVM -Duane.


 Original Message 
Subject: [lldb-dev] Structure variable names
From: Jiten Thakkar via lldb-dev 
Date: Tue, June 07, 2016 9:56 am
To: lldb-dev@lists.llvm.org

Hi All,
I am working on a project as part of my graduate study which uses LLVM.
I am new to LLVM and lldb to be particular.
My goal is to get names of the parameters to functions. If the parameter is a variable in a structure, it is represented as an offset in the structure.
I want to get the names of all those parameters. I assume that debug info should provide this but so far I am unable to find any documentation regarding which would describe how to do it. 
Is there a way to do this using debug info? Is this even possible?
Please let me know if any of this is confusing and I will try to describe it in detail.

Thanks,
Jiten
___
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] Structure variable names

[Greg Clayton via lldb-dev]

> On Jun 7, 2016, at 9:56 AM, Jiten Thakkar via lldb-dev 
>  wrote:
> 
> Hi All,
> I am working on a project as part of my graduate study which uses LLVM.
> I am new to LLVM and lldb to be particular.
> My goal is to get names of the parameters to functions. If the parameter is a 
> variable in a structure, it is represented as an offset in the structure.

This is possible. First you will want to get a lldb::SBFunction that represents 
the function whose parameters you want. If you use the current frame, you can 
get this info quickly in python:

% lldb a.out
(lldb) b main
(lldb) r

... run and hit breakpoint

(lldb) script
>>> func = lldb.frame.GetFunction()
>>> print func
SBFunction: id = 0x002e, name = main, type = main

Now we can ask the function for its top lexical block and ask that block to 
fetch a list of SBValue objects that represent the parameters only (no locals, 
or statics):

>>> get_parameters = True
>>> get_locals = False
>>> get_statics = False
>>> parameters = func.GetBlock().GetVariables(lldb.frame, get_parameters, 
>>> get_locals, get_statics, lldb.eDynamicDontRunTarget)
>>> print parameters
(int) argc = 1
(const char **) argv = 0x7fff5fbff8f8
(const char **) envp = 0x7fff5fbff908
(const char **) aapl = 0x7fff5fbffa30


"parameters" is a SBValueList so you can iterate through it by index:

>>> num_params = params.GetSize()
>>> print num_params
4
>>> for i in range(num_params):
...   param = params.GetValueAtIndex(i)
...   print param
... 
(int) argc = 1
(const char **) argv = 0x7fff5fbff8f8
(const char **) envp = 0x7fff5fbff908
(const char **) aapl = 0x7fff5fbffa30

Now you want to explore the types of each parameter:

>>> for i in range(num_params):
...   param = params.GetValueAtIndex(i)
...   param_type = param.GetType()
...   print param_type
... 

You now "param_type" that has a SBType object that represents the type of each 
parameter. You can ask it:

>>> print param_type.GetTypeClass()

This will return an enum that is one of:

eTypeClassInvalid   
eTypeClassArray 
eTypeClassBlockPointer  
eTypeClassBuiltin   
eTypeClassClass 
eTypeClassComplexFloat  
eTypeClassComplexInteger
eTypeClassEnumeration   
eTypeClassFunction  
eTypeClassMemberPointer 
eTypeClassObjCObject
eTypeClassObjCInterface 
eTypeClassObjCObjectPointer 
eTypeClassPointer   
eTypeClassReference 
eTypeClassStruct
eTypeClassTypedef   
eTypeClassUnion 
eTypeClassVector


If this value is eTypeClassClass, eTypeClassStruct or eTypeClassUnion, you can 
access the fields:

type_class = param_type.GetTypeClass()
if type_class == lldb.eTypeClassClass or type_class == lldb.eTypeClassStruct or 
type_class == lldb.eTypeClassUnion:
num_fields = param_type.GetNumberOfFields()
for field_idx in range(num_fields):
member = param_type.GetFieldAtIndex(field_idx)

This class is a SBTypeMember which can tell you the info you want:

class SBTypeMember
{
public:
SBTypeMember ();

SBTypeMember (const lldb::SBTypeMember& rhs);

~SBTypeMember();

lldb::SBTypeMember&
operator = (const lldb::SBTypeMember& rhs);

bool
IsValid() const;

const char *
GetName ();

lldb::SBType
GetType ();

uint64_t
GetOffsetInBytes();

uint64_t
GetOffsetInBits();

bool
IsBitfield();

uint32_t
GetBitfieldSizeInBits();

bool
GetDescription (lldb::SBStream , 
lldb::DescriptionLevel description_level);
}




> I want to get the names of all those parameters. I assume that debug info 
> should provide this but so far I am unable to find any documentation 
> regarding which would describe how to do it. 
> Is there a way to do this using debug info? Is this even possible?
> Please let me know if any of this is confusing and I will try to describe it 
> in detail.

This should get you started. There is also an example that checks for padding 
within types:

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

This checks for padding within a type to show you gaps in your classes and 
structs.

All of the example above are in python, but this same API is available in C++ 
if you need it. We have docs covering our APIs here:

Python:

http://lldb.llvm.org/python_reference/index.html

C++:

http://lldb.llvm.org/cpp_reference/html/index.html


You will be interested in SBFunction, SBType and SBTypeMember.

Let me know if you have any questions,

Greg Clayton


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

[lldb-dev] Structure variable names

[Jiten Thakkar via lldb-dev]

Hi All,
I am working on a project as part of my graduate study which uses LLVM.
I am new to LLVM and lldb to be particular.
My goal is to get names of the parameters to functions. If the parameter is a 
variable in a structure, it is represented as an offset in the structure.
I want to get the names of all those parameters. I assume that debug info 
should provide this but so far I am unable to find any documentation regarding 
which would describe how to do it. 
Is there a way to do this using debug info? Is this even possible?
Please let me know if any of this is confusing and I will try to describe it in 
detail.

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

Re: [lldb-dev] Release_38 cherry-picks

[Greg Clayton via lldb-dev]

All of those look simple enough. Two are for testing only and the last one is a 
simple fix needed for PIE exe debugging.

Greg Clayton

> On Jun 6, 2016, at 4:22 PM, Francis Ricci via lldb-dev 
>  wrote:
> 
> Hi all,
> 
> I'd like to merge a few more small bugfixes onto the 38 release
> branch. I'll plan to do it tomorrow (3/7) in the evening if I don't
> hear any objections. Thanks!
> 
> r259433 - Fix getCompiler in unit testing framework on compiler symlinks
> r267459 - Add missing qRegisterInfo option to gdbremote testcase
> r271899 - Don't remove PIE executables when using svr4 packets
> 
> Francis
> ___
> 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] Catching async debugger output

[Greg Clayton via lldb-dev]

No there is no way as this is async output that isn't tagged to any specific 
command.

My suggestion is to not use command line stop hooks and catch the stops in your 
python and do the stuff that you were doing with stop hooks by using the python 
API. 

Greg

> On Jun 6, 2016, at 7:05 PM, Vadim Chugunov via lldb-dev 
>  wrote:
> 
> Hello,
> Is there a way for a python script to catch asynchronous debugger output, 
> such as the output of stop hooks?  I've tried attaching a listener to 
> CommandInterpreter's broadcaster, but no events seem to be ever fired.  
> Anything else I should try?
> 
> thanks!
> ___
> 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] Release_38 cherry-picks

[Daniel Sanders via lldb-dev]

Hi,

You should get approval from the release manager (Tom Stellard) first.

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Francis
> Ricci via lldb-dev
> Sent: 07 June 2016 00:23
> To: LLDB
> Subject: [lldb-dev] Release_38 cherry-picks
> 
> Hi all,
> 
> I'd like to merge a few more small bugfixes onto the 38 release
> branch. I'll plan to do it tomorrow (3/7) in the evening if I don't
> hear any objections. Thanks!
> 
> r259433 - Fix getCompiler in unit testing framework on compiler symlinks
> r267459 - Add missing qRegisterInfo option to gdbremote testcase
> r271899 - Don't remove PIE executables when using svr4 packets
> 
> Francis
> ___
> 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