Re: [lldb-dev] LLDB Evolution

[Pavel Labath via lldb-dev]

I've sampled the python code from the llvm repository, and it seems to
be using a mixture of 4-, 2-, and even 8- character indent, with 4
being the most prevalent. So, I think we can safely stay with status
quo.

It will take some editor tweaking to make it use the correct indent
for different files, but it should be manageable.

pl

On 12 August 2016 at 18:13, Jim Ingham  wrote:
>
>> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev 
>>  wrote:
>>
>> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
>>  wrote:
>>> I recommend approaching this in three steps:
>>>
>>> 1) get the less-controversial changes done that Greg was outlining.
>>> 2) start a discussion in the llvm community about the concept of a
>>> member/global prefix.
>>> 2a) the community could agree that llvm-as-a-whole should move to prefixes
>>> or otherwise change the camel case policy.
>>> 2b) the community could agree that the existing policies are preferred
>>> 3) LLDB moves to whatever is the end result of the discussion.
>>>
>>> I guess what I’m saying is that since the opinions about this are very
>>> strong, and because we haven’t really had that debate in the LLVM community,
>>> that it would be bad to proactively move to the LLVM style, simply to have
>>> to move back later.  Iff the (sure to be extensive) community discussion
>>> settles on the idea that prefixes are the wrong thing, then LLDB should
>>> remove them to be consistent.
>>>
>>> -Chris
>>
>> +1
>>
>>
>>
>> In terms of the formatting of tests, I did some more research on this.
>> I think the changes needed to be made to the test suite are generally
>> trivial to fix (e.g. r278490), but I don't think we can avoid a manual
>> intervention. CommentPragmas does not seem to be a silver bullet -- it
>> does prevent clang-format from breaking the comment, but it does not
>> prevent it from moving the whole comment to a new line. That said,
>> when I reformatted the test sources with CommentPragmas set, the
>> number of failures went down to 80 (from about 150)...
>>
>> I believe we should still perform the reformatting of the tests, at
>> least to standardize on the 2 space indent (in fact we should consider
>> doing the same for the python code as well, I don't know what's the
>> situation there in llvm land), but it can be done later. It will make
>> the period while the code is in flux longer, but hopefully not too
>> long. Also the modifications will be independent of the main reformat,
>> so it will still be true that a single source file only got
>> reformatted once.
>>
>
> My eyes put in a vote for not reformatting the Python to 2 space tabs. In 
> C++, most IDE's do smart things with double-clicking on { to find the closing 
> ones easing the task that two space indents makes somewhat harder.  But since 
> the spacing is the only nesting indicator in Python, it would be nice to keep 
> that more visually apparent.
>
>> 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] LLDB Evolution

[David Jones via lldb-dev]

On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I've sampled the python code from the llvm repository, and it seems to
> be using a mixture of 4-, 2-, and even 8- character indent, with 4
> being the most prevalent. So, I think we can safely stay with status
> quo.
>
>
(Comment from the peanut gallery...)

Python does have a language-level style guide (PEP-8):

https://www.python.org/dev/peps/pep-0008/

If code is going to be reformatted, then it may be best to try to converge
on exactly the PEP-8 style. Speaking as a project "outsider" (i.e., not an
active contributor), but someone with Python background, anything that
diverges from standard Python style seems jarring (at least to me).



> It will take some editor tweaking to make it use the correct indent
> for different files, but it should be manageable.
>
> pl
>
> On 12 August 2016 at 18:13, Jim Ingham  wrote:
> >
> >> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
> >>  wrote:
> >>> I recommend approaching this in three steps:
> >>>
> >>> 1) get the less-controversial changes done that Greg was outlining.
> >>> 2) start a discussion in the llvm community about the concept of a
> >>> member/global prefix.
> >>> 2a) the community could agree that llvm-as-a-whole should move to
> prefixes
> >>> or otherwise change the camel case policy.
> >>> 2b) the community could agree that the existing policies are preferred
> >>> 3) LLDB moves to whatever is the end result of the discussion.
> >>>
> >>> I guess what I’m saying is that since the opinions about this are very
> >>> strong, and because we haven’t really had that debate in the LLVM
> community,
> >>> that it would be bad to proactively move to the LLVM style, simply to
> have
> >>> to move back later.  Iff the (sure to be extensive) community
> discussion
> >>> settles on the idea that prefixes are the wrong thing, then LLDB should
> >>> remove them to be consistent.
> >>>
> >>> -Chris
> >>
> >> +1
> >>
> >>
> >>
> >> In terms of the formatting of tests, I did some more research on this.
> >> I think the changes needed to be made to the test suite are generally
> >> trivial to fix (e.g. r278490), but I don't think we can avoid a manual
> >> intervention. CommentPragmas does not seem to be a silver bullet -- it
> >> does prevent clang-format from breaking the comment, but it does not
> >> prevent it from moving the whole comment to a new line. That said,
> >> when I reformatted the test sources with CommentPragmas set, the
> >> number of failures went down to 80 (from about 150)...
> >>
> >> I believe we should still perform the reformatting of the tests, at
> >> least to standardize on the 2 space indent (in fact we should consider
> >> doing the same for the python code as well, I don't know what's the
> >> situation there in llvm land), but it can be done later. It will make
> >> the period while the code is in flux longer, but hopefully not too
> >> long. Also the modifications will be independent of the main reformat,
> >> so it will still be true that a single source file only got
> >> reformatted once.
> >>
> >
> > My eyes put in a vote for not reformatting the Python to 2 space tabs.
> In C++, most IDE's do smart things with double-clicking on { to find the
> closing ones easing the task that two space indents makes somewhat harder.
> But since the spacing is the only nesting indicator in Python, it would be
> nice to keep that more visually apparent.
> >
> >> 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
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 28989] New: lldb not sending SIGINT to inferior process

[via lldb-dev]

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

Bug ID: 28989
   Summary: lldb not sending SIGINT to inferior process
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: pen...@apple.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 16958
  --> https://llvm.org/bugs/attachment.cgi?id=16958&action=edit
Source file main.c used to reproduce issue

When lldb connects to a previously launchd process via pid, issuing ^C (Ctrl-C)
in the tty of the inferior process correctly sends SIGINT to the inferior
process. At this point, commands to `process handle SIGINT ...` can be used to
route the signal as the user wants.

However, if the inferior process is launched by lldb itself, either via `lldb
./some_bin` at the command line, or via `target create ...` from within lldb;
Ctrl-C is only received by lldb, and cannot be forwarded to the inferior
process as a SIGINT.

Note that sending a SIGINT to the debugged process with kill(1) or kill(2) will
work, but is only a workaround.

= Produce executable from attached source =

$ clang -g -o main main.c

= Attach to pid =

# launch ./main in separate tty

(lldb) pr at -p N
(lldb) pr ha SIGINT -p true -s false
(lldb) c

# issue ^C in tty running ./main
# ./main process exits via custom handler as intended

= Launch from inside lldb =

$ lldb
(lldb) ta cr ./main
(lldb) br s -n main
(lldb) r
Process N stopped ... stop reason = signal SIGSTOP
[...]
(lldb) pr ha SIGINT -p true -s false
(lldb) c
^C
Process N stopped ... stop reason = signal SIGSTOP
[...]

# ^C never results in a SIGINT to inferior process

-- 
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] Search C++ "virtual" objects

[Lei Kong via lldb-dev]

Thanks much for all the useful information!

I was able to get all vtable information with the following command, but is 
there an API I could use in an extension? I have checked the obvious ones 
“SBSymbol*”, they do not seem to have functions for iterating/searching symbols.

image lookup -A  -r -v -s "vtable"

Sent from Mail for Windows 10

From: Greg Clayton
Sent: Friday, August 12, 2016 05:25 PM
To: Lei Kong
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Search C++ "virtual" objects


> On Aug 12, 2016, at 4:55 PM, Lei Kong via lldb-dev  
> wrote:
>
> On Linux, given a core dump file, an executable and its symbols, is it 
> possible to do the following in LLDB (maybe with a LLDB extension)?
>
> 1.   Get the list of all C++ virtual types (classes with virtual function 
> table)

You will be able to find all vtable symbols in the symbol tables of the 
executable and shared libraries that you have. Not sure if the system libraries 
on linux have the vtable symbols in the symbol tables of the shared libraries. 
If you can download the separate debug info for the shared libraries that might 
help.

If you made a core file on your current machine and you are trying to look at 
this core file on the same machine without any shared libraries having been 
updated, then you might if the vtable symbols are in your executables in the 
symbol tables as you said.

So the answer is maybe. Depends on how good your symbol tables are for the 
executables and sharerd libraries that contain virtual classes that you care 
about.

> 2.   Search the whole address space to find all instances of such 
> objects? (false positives are okay)

You should be able to iterate through all of the memory segments using:

lldb::SBMemoryRegionInfoList
GetMemoryRegions();

This is a relatively new thing that was added to LLDB in the last few months so 
you will need a pretty recent LLDB. But this will give you all of the memory 
regions in your current process. You can then look at the permissions of each 
regions to make sure the regions is writable. So you can try this in python:

(lldb)
regions = lldb.process.GetMemoryRegions();
num_regions = regions.GetSize()
region = lldb.SBMemoryRegionInfo()
error = lldb.SBError()
for i in range(num_regions):
  if regions.GetMemoryRegionAtIndex(i, region):
if region.IsWritable():
  addr = region.GetRegionBase()
  end_addr = region.GetRegionEnd()
  bytes = process.ReadMemory(addr, end_addr - addr, error)
  // Bytes is a binary python string so you can search it for the vtable 
pointer of your choosing


>
> If #1 is not possible, then how about getting virtual function table address 
> of a given type (without an object)?

There should be symbols in the symbol tables that are the vtable symbols and 
you can look them up by name. For example, on MacOSX, if you compile the 
following:

class A
{
public:
A(int a) : m_a(a) {}
virtual ~A() {}
protected:
int m_a;
};
int main (int argc, char const *argv[], char const *envp[])
{
A *a_ptr= new A(123);
return 0;
}




You get a symbol table of:

(lldb) image dump symtab a.out
Symtab, file = /private/tmp/a.out, num_symbols = 19:
   Debug symbol
   |Synthetic symbol
   ||Externally Visible
   |||
Index   UserID DSX TypeFile Address/Value Load Address   Size   
Flags  Name
--- -- --- --- -- -- 
-- -- --
[0]  0 D   SourceFile  0x
Sibling -> [   12] 0x0064 /tmp/main.cpp
[1]  2 D   ObjectFile  0x57ae67f1
0x 0x00660001 
/var/folders/2y/y20b92093flcz2qdwwpf5b6c0007k2/T/main-fb7ae1.o
[2]  4 D X Code0x00010e00 0x00010e00 
0x0080 0x000f main
[3]  8 D   Code0x00010e80 0x00010e80 
0x0030 0x001e0080 A::A(int)
[4] 12 D   Code0x00010eb0 0x00010eb0 
0x0030 0x001e0080 A::A(int)
[5] 16 D   Code0x00010ee0 0x00010ee0 
0x0020 0x001e0080 A::~A()
[6] 20 D   Code0x00010f00 0x00010f00 
0x0030 0x001e0080 A::~A()
[7] 24 D   Code0x00010f30 0x00010f30 
0x000a 0x001e0080 A::~A()
[8] 27 D   Data0x00010f68 0x00010f68 
0x002c 0x000e GCC_except_table0
[9] 28 D X Data0x00010f94 0x00010f94 
0x0003 0x000f0080 typeinfo name for A
[   10] 29 D X Data0x00011038 0x00011038 
0x0020 0x001e0080 vta

Re: [lldb-dev] Search C++ "virtual" objects

[Lei Kong via lldb-dev]

Should I use lldb::SBTarget::GetModuleAtIndex() to get all modules and then 
lldb::SBModule::GetSymbolAtIndex() to go through all symbols?
Thanks.

Sent from Mail for Windows 10

From: Lei Kong via lldb-dev
Sent: Monday, August 15, 2016 04:44 PM
To: Greg Clayton
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Search C++ "virtual" objects

Thanks much for all the useful information!

I was able to get all vtable information with the following command, but is 
there an API I could use in an extension? I have checked the obvious ones 
“SBSymbol*”, they do not seem to have functions for iterating/searching symbols.

image lookup -A  -r -v -s "vtable"

Sent from Mail for Windows 10

From: Greg Clayton
Sent: Friday, August 12, 2016 05:25 PM
To: Lei Kong
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Search C++ "virtual" objects


> On Aug 12, 2016, at 4:55 PM, Lei Kong via lldb-dev  
> wrote:
>
> On Linux, given a core dump file, an executable and its symbols, is it 
> possible to do the following in LLDB (maybe with a LLDB extension)?
>
> 1.   Get the list of all C++ virtual types (classes with virtual function 
> table)

You will be able to find all vtable symbols in the symbol tables of the 
executable and shared libraries that you have. Not sure if the system libraries 
on linux have the vtable symbols in the symbol tables of the shared libraries. 
If you can download the separate debug info for the shared libraries that might 
help.

If you made a core file on your current machine and you are trying to look at 
this core file on the same machine without any shared libraries having been 
updated, then you might if the vtable symbols are in your executables in the 
symbol tables as you said.

So the answer is maybe. Depends on how good your symbol tables are for the 
executables and sharerd libraries that contain virtual classes that you care 
about.

> 2.   Search the whole address space to find all instances of such 
> objects? (false positives are okay)

You should be able to iterate through all of the memory segments using:

lldb::SBMemoryRegionInfoList
GetMemoryRegions();

This is a relatively new thing that was added to LLDB in the last few months so 
you will need a pretty recent LLDB. But this will give you all of the memory 
regions in your current process. You can then look at the permissions of each 
regions to make sure the regions is writable. So you can try this in python:

(lldb)
regions = lldb.process.GetMemoryRegions();
num_regions = regions.GetSize()
region = lldb.SBMemoryRegionInfo()
error = lldb.SBError()
for i in range(num_regions):
  if regions.GetMemoryRegionAtIndex(i, region):
if region.IsWritable():
  addr = region.GetRegionBase()
  end_addr = region.GetRegionEnd()
  bytes = process.ReadMemory(addr, end_addr - addr, error)
  // Bytes is a binary python string so you can search it for the vtable 
pointer of your choosing


>
> If #1 is not possible, then how about getting virtual function table address 
> of a given type (without an object)?

There should be symbols in the symbol tables that are the vtable symbols and 
you can look them up by name. For example, on MacOSX, if you compile the 
following:

class A
{
public:
A(int a) : m_a(a) {}
virtual ~A() {}
protected:
int m_a;
};
int main (int argc, char const *argv[], char const *envp[])
{
A *a_ptr= new A(123);
return 0;
}




You get a symbol table of:

(lldb) image dump symtab a.out
Symtab, file = /private/tmp/a.out, num_symbols = 19:
   Debug symbol
   |Synthetic symbol
   ||Externally Visible
   |||
Index   UserID DSX TypeFile Address/Value Load Address   Size   
Flags  Name
--- -- --- --- -- -- 
-- -- --
[0]  0 D   SourceFile  0x
Sibling -> [   12] 0x0064 /tmp/main.cpp
[1]  2 D   ObjectFile  0x57ae67f1
0x 0x00660001 
/var/folders/2y/y20b92093flcz2qdwwpf5b6c0007k2/T/main-fb7ae1.o
[2]  4 D X Code0x00010e00 0x00010e00 
0x0080 0x000f main
[3]  8 D   Code0x00010e80 0x00010e80 
0x0030 0x001e0080 A::A(int)
[4] 12 D   Code0x00010eb0 0x00010eb0 
0x0030 0x001e0080 A::A(int)
[5] 16 D   Code0x00010ee0 0x00010ee0 
0x0020 0x001e0080 A::~A()
[6] 20 D   Code0x00010f00 0x00010f00 
0x0030 

Re: [lldb-dev] LLDB Evolution

[Chris Lattner via lldb-dev]

> On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev 
>  wrote:
> 
> On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> I've sampled the python code from the llvm repository, and it seems to
> be using a mixture of 4-, 2-, and even 8- character indent, with 4
> being the most prevalent. So, I think we can safely stay with status
> quo.
> 
> 
> (Comment from the peanut gallery...)
> 
> Python does have a language-level style guide (PEP-8):
> 
> https://www.python.org/dev/peps/pep-0008/ 
> 
> 
> If code is going to be reformatted, then it may be best to try to converge on 
> exactly the PEP-8 style. Speaking as a project "outsider" (i.e., not an 
> active contributor), but someone with Python background, anything that 
> diverges from standard Python style seems jarring (at least to me).

Also from the peanut gallery, but +1 for standardizing python code on the PEP-8 
standards.

-Chris

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