Re: [lldb-dev] [Release-testers] [9.0.0 Release] Release Candidate 1 is here

[Michał Górny via lldb-dev]

On Mon, 2019-07-29 at 16:32 +0200, Hans Wennborg via Release-testers
wrote:
> Hi everyone,
> 
> 9.0.0-rc1 was just tagged from the release_90 branch at r367217
> (tagged as llvmorg-9.0.0-rc1 in the Git monorepo).
> 
> Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc1
> 
> Binaries will be added as they become available.
> 
> Please file bug reports for any issues you find as blockers of
> https://llvm.org/PR42474
> 
> Release testers: please start your engines, run the script, share your
> results, and upload binaries.
> 

I've reported a regression with lit test suite [1], and LLDB is still
broken on Gentoo (maybe I'll manage to get it fixed for -11? ;-)). 
Other than that, it looks fine.

[1] https://bugs.llvm.org/show_bug.cgi?id=42812

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] RFC: changing variable naming rules in LLVM codebase & git-blame

[Raphael “Teemperor” Isemann via lldb-dev]

Is the plan for LLDB to just adapt the code that is trying to follow the new 
code style or also the code using the LLDB code style?

I’m in general in favor of moving LLDB to the LLVM code style because it makes 
the LLDB code that interfaces with Clang/LLVM less awkward to write (e.g. no 
more code style confusion when inheriting from a Clang classes inside the LLDB 
code base). But I think if we do this, then it should be discussed/planned in 
more detail and in a lldb-dev thread that actually reaches all/most LLDB devs. 
I wouldn’t even have read this thread if Pavel didn’t CC lldb-dev.

As a side note: LLDB has downstream projects that will suffer from this, but I 
believe (?) LLD has no downstream projects. So I think LLD is maybe also a good 
candidate to test this?

- Raphael


> On Jul 30, 2019, at 8:38 AM, Pavel Labath via llvm-dev 
>  wrote:
> 
> On 30/07/2019 01:57, Chris Lattner via llvm-dev wrote:
>> On Jul 29, 2019, at 10:58 AM, JF Bastien > > wrote:
 I think that Rui rolled this out in an incredibly great way with LLD, 
 incorporating a lot of community feedback and discussion, and (as you say) 
 this thread has accumulated many posts and a lot of discussion, so I don’t 
 see the concern about lack of communication.
>>> 
>>> I think there’s lack of proper communication for this effort. The RFC is 
>>> all about variable naming, with 100+ responses. Sounds like a bikeshed I’ve 
>>> happily ignored, and I know many others have. Even if you don’t think I’m 
>>> right, I’d appreciate a separate RFC with details of what’s actually being 
>>> proposed. Off the top of my head I’d expect at least these questions 
>>> answered:
>>> 
>>>  * What’s the final naming convention?
>>>  * Will we have tools to auto-flag code that doesn’t follow it, and
>>>can auto-fix it?
>>>  * Will we clang-format everything while we’re at it?
>>>  * Will we run clang modernizer to move code to C++11 / C++14 idioms
>>>while we’re doing all this?
>>>  * What’s the timeline for this change?
>>>  * Is it just a single huge commit?
>>>  * After the monorepo and GitHub move?
>>>  * Is there a dev meeting roundtable scheduled?
>>>  * What tooling exists to ease transition?
>>>  * Out-of-tree LLVM backends are a normal thing. They use internal
>>>LLVM APIs that should all be auto-updatable, has this been tried?
>>>  * Some folks have significant non-upstream code. Have they signed up
>>>to remedy that situation before the deadline (either by
>>>upstreaming or trying out auto-update scripts)?
>>> 
>>> 
>>> LLD and LLDB are indeed good small-scale experiments. However, I think the 
>>> rest of the project is quite different in the impact such a change would 
>>> have. LLVM and clang expose many more C++ APIs, and have many more 
>>> out-of-tree changes (either on top of upstream, or in sub-folders such as 
>>> backends or clang tools). They also have many more contributors affected, 
>>> and not all those contributors have the same constraints, making this much 
>>> more complex. So far this discussion hasn’t seemed to care about these 
>>> concerns, and I’m worried we’re about to burn a bunch of bridges. Maybe I 
>>> missed this part of the discussion in the 100+ emails! Sorry if I did… but 
>>> again, a simple updated RFC would solve everything.
>> Thanks for the detailed list here.  I have no idea what the status of most 
>> of these are - it sounds like you’re generally asking “what is the plan?” 
>> beyond LLD.  :-)
>> Rui, what are your thoughts on next steps?  LLDB seems like a logical step, 
>> particularly because it uses its own naming convention that is completely 
>> unlike the rest of the project.
> 
> I don't speak for LLDB, but I personally would welcome such a change, 
> particularly as there is some newer code in lldb now that attempts to follow 
> the about-to-be-changed llvm conventions.
> 
> If we're going to go in that direction, it would be good to loop in lldb-dev, 
> as I think some people don't follow llvm-dev regularly (and this thread in 
> particular).
> 
> pl
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [llvm-dev] RFC: changing variable naming rules in LLVM codebase & git-blame

[Pavel Labath via lldb-dev]

On 30/07/2019 11:53, Raphael “Teemperor” Isemann wrote:

Is the plan for LLDB to just adapt the code that is trying to follow the new 
code style or also the code using the LLDB code style?


I don't think there's a "plan" at this moment, but I believe Chris meant 
all of LLDB.




I’m in general in favor of moving LLDB to the LLVM code style because it makes 
the LLDB code that interfaces with Clang/LLVM less awkward to write (e.g. no 
more code style confusion when inheriting from a Clang classes inside the LLDB 
code base). But I think if we do this, then it should be discussed/planned in 
more detail and in a lldb-dev thread that actually reaches all/most LLDB devs. 
I wouldn’t even have read this thread if Pavel didn’t CC lldb-dev.

As a side note: LLDB has downstream projects that will suffer from this, but I 
believe (?) LLD has no downstream projects. So I think LLD is maybe also a good 
candidate to test this?


The details of this may have gotten lost in the long thread, but 
actually, LLD has gone through the reformatting in the beginning of this 
month. You can look up the details in the thread, but the short summary 
is that it was done via an automated script in a manner very similar to 
the Great LLDB Reformat a couple of years ago. Judging by the thread, 
there are downstream lld users, and while they encountered some hickups, 
it looks like the overall merge process has been relatively painless.


The topic of discussion now is "where do we go from here" and LLDB has 
been proposed as the next step.


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

Re: [lldb-dev] STABS

[Pavel Labath via lldb-dev]

On 26/07/2019 20:43, Jim Ingham wrote:

Amplifying Fred's comments:

Most of the code in ParseSymtab is parsing the nlist records in the binary.  Only a tiny 
subset of those nlist records are "stabs".  Most are just the format by which 
MachO expresses its symbol table.  So all that needs to be there.

Over the past couple of years, the linker on MachO has switched from using 
nlist records to using the dyld trie data structure.  You can also see evidence 
of that in ParseSymtab.  At this point the nlist records are there because 
there are lots of analysis tools that haven't been updated to support the new 
dyld trie.  At some point, everything will be updated and the linker will 
switch over to only emitting the dyld trie, and not emitting the symbol table 
in nlist form.  When that is done and we convince ourselves we no longer need 
to support older binaries that still use nlist records, we can then remove the 
nlist parsing code.  But until then, this is how the symbol table is expressed. 
 The symbol parsing is actually the majority of the code in ParseSymtab.

Not all nlist records are stabs.  Stabs, per se, are the nlist records that have the 
is_debug flag set.  As Fred said, MachO uses the debug nlist records as the format for 
it's "debug map" which tells us where symbols from .o files ended up in the 
final linked product.  This is definitely NOT a stabs parser, we only support a tiny 
subset of the full stabs debug format, just what is needed for the debug map.  We've 
talked on and off about coming up with a dedicated format for the debug map, but so far 
there's been no strong motivation to actually do that, so we've continued to borrow a 
subset of stabs for the purpose.

There is one bit of ugliness, which is that the debug map parsing is essentially duplicated.  Look 
for: "if (is_debug)" and you will see two very similar blocks (2860 and 3826 in the 
current sources.)  Jason will remember the details better, but there was something gnarly about how 
libraries in the "shared cache" on Darwin systems work that made it awkward to use the 
same code for it and normal libraries.  Some ambitious person could probably go through and unify 
the two sections, but this is code that doesn't see much active development, it pretty much does 
what's needed, so it's not clear what the benefit would be at this point.

  Jim



Thanks for the detailed explanation Jim. I've found it very useful, as 
it plugs a large gap I've had in the knowledge of how debug info works 
on apple platforms.


The reason I was looking at this code in the first place is because I'm 
trying to add unwinding support on windows platforms. It is mostly 
straight-forward, but there is one large hickup in the form of the 
__stdcall calling convention on x86. This is a callee-cleanup 
convention, which AFAICT is a new thing to lldb.


The interesting bit here is that it becomes important to know the size 
of the arguments to a function during unwinding. This size is encoded in 
the symbol names (e.g. "_foo@4"). Due to the way that unwind info is 
represented (the argument pushes aren't represented in the caller, it 
may be necessary to look at the argument size of one function (callee) 
when unwinding another function (caller).


I was hoping I could represent this information in the Symbol class 
without increasing its size. Hence I was looking at the various other 
bits of information stored in there, and seeing if any of those can be 
removed.


Anyway, it looks like the "stabs" code and the various Symtab bits 
associated with it are going to stay. I'm not sure yet what does this 
mean for my unwinding effort, as I am still in the process learning how 
this stuff actually works, and whether the Symtab stuff is really 
needed, but I figured it would be good to at least explain the my 
motivations here.



On 26/07/2019 22:57, Chris Bowler wrote:> IBM is currently adding 
support for AIX to LLVM and we still have

> customers that use STABS for debug.  I expect customers to try to move
> to DWARF but I think the DWARF support on AIX needs some improvement
> before we can fully transition. I kindly request that we defer removal
> of the STABS support until IBM has a better handle on whether or not
> we'll want it for AIX.

Chris,

it seems that the code in question is going to stay for a while. 
Unfortunately, it looks like it won't be of much use to you, should you 
decide to add STABS support to lldb (it is in macho-specific parts of 
code, and is not a real STABS parser anyway).


Cheers,
pavel

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

[lldb-dev] August LLVM bay-area social is this Thursday!

[George Burgess IV via lldb-dev]

We'll be at Tied House as usual, starting on Thursday the 1st at 7pm!

If you can, help us plan and RSVP here:
https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzlbcb/

See everyone there!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 40189] LLDB expressions always error if a C++ local variable is named after a keyword

[via lldb-dev]

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

Jonas Devlieghere  changed:

   What|Removed |Added

 CC||jdevliegh...@apple.com
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Jonas Devlieghere  ---
This was fixed by https://reviews.llvm.org/rL359773

bash-3.2$ echo 'int main(int argc){__func__;}' | g++ -g -x c++ - && lldb -o 'br
s -n main' -o 'pr la' -o 'expr argc' a.out
:1:5: warning: only one parameter on 'main' declaration [-Wmain]
int main(int argc){__func__;}
^
:1:20: warning: expression result unused [-Wunused-value]
int main(int argc){__func__;}
   ^~~~
2 warnings generated.
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) br s -n main
Breakpoint 1: where = a.out`main + 9 at :1:29, address =
0x00010fa9
(lldb) pr la
Process 51065 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010fa9 a.out`main(argc=1) at :1:29
Target 0: (a.out) stopped.

Process 51065 launched: '/private/tmp/a.out' (x86_64)
(lldb) expr argc
(int) $0 = 1

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

[lldb-dev] [Bug 20466] Inspecting variable with same name as a type does not work

[via lldb-dev]

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

Jonas Devlieghere  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||jdevliegh...@apple.com

--- Comment #2 from Jonas Devlieghere  ---
lldb) target create "/tmp/a.out"
Current executable set to '/tmp/a.out' (x86_64).
(lldb) b main.cpp:5
Breakpoint 1: where = a.out`main + 15 at main.cpp:8:14, address =
0x00010f7f
(lldb) r
Process 53813 launched: '/tmp/a.out' (x86_64)
Process 53813 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010f7f a.out`main at main.cpp:8:14
   5int main()
   6{
   7  Foo Foo;
-> 8  return Foo.Bar();
   9}
(lldb) p Foo.Bar();
(int) $0 = 10

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

[lldb-dev] Bug report, lldb 8.0.1 python binding is not correctly generated

[Joey Xie via lldb-dev]

I'm using vscode and CodeLLDB to debug rust code.

```text
Internal debugger error:
Traceback (most recent call last):
  File
"/home/joey/.vscode/extensions/vadimcn.vscode-lldb-1.2.3/adapter/debugsession.py",
line 1366, in handle_message
result = handler(args)
  File
"/home/joey/.vscode/extensions/vadimcn.vscode-lldb-1.2.3/adapter/debugsession.py",
line 426, in DEBUG_setBreakpoints
result = self.set_source_breakpoints(file_bps, req_bps, file_id)
  File
"/home/joey/.vscode/extensions/vadimcn.vscode-lldb-1.2.3/adapter/debugsession.py",
line 447, in set_source_breakpoints
for bp_loc in bp:
TypeError: 'SBBreakpoint' object is not iterable
```

I checked my `/usr/lib/python2.7/site-packages/lldb/__init__.py` file, the
`SBBreakpoint` class lack a `__iter__` method, but In the document at
https://lldb.llvm.org/python_reference/index.html `SBBreakpoint` class has
a `__iter__` method.

I guess it may be a bug that when generating the python binding for lldb
8.0.1 some methods are missing, can someone confirm this bug? thanks!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev