Re: [lldb-dev] [llvm-dev] Optimised-code debugging experience Round Table

[Eric Christopher via lldb-dev]

Hi Paul,

I took it rather as a set of suggested topics depending on who is
interested rather than a proposed agenda.

-eric

On Wed, Sep 23, 2020 at 7:20 AM Robinson, Paul 
wrote:

> Hi Eric & Orlando,
>
>
>
> It’s great to see interest in a lot of different aspects of debug info. At
> the same time, I’m concerned about a risk to making the topic so broad that
> we don’t have time to get through all the things people want to get
> through.  I’m thinking there’s a different way to slice the topics,
> hopefully without much overlap, but that will allow a bit more focus.  No
> doubt a lot of the same people would be interested in multiple slices, but
> by limiting the scope of each conversation I’m hoping we’ll get more
> accomplished.  I daresay a lot of people interested in debug-info quality
> in general might totally tune out a DWARF-nerd discussion 
>
> The slicing could be something like this:
>
>
>
>1. Getting LLVM to do a better job of tracking info internally, so
>what gets emitted in the end is more representative of the original
>program. This should improve the debugging experience by letting the
>debugger do a better job of mapping the executing program to the original
>source, because the data it works with is more accurate/complete.
>   1. This is basically about IR/Metadata handling and representation,
>   although it might leak into things like the “is_stmt” flag, and doing
>   better with “prologue_end,” which are currently handled by AsmPrinter.
>   2. Better handling of induction variables, entry-values, variables
>   with multiple locations, etc.
>2. Changes to optimization passes/pipelines and codegen, to avoid
>borking the source-location and value/variable tracking; again this should
>improve the debugging experience by letting the debugger do a better job of
>mapping the executing program back to the original source, because that
>mapping is simpler.
>   1. This is basically about IR/MIR transforms, and is where an Og/O1
>   kind of topic would fit.
>   2. Also things like extended lifetimes, limiting code
>   motion/duplication, etc.
>3. Changing the DWARF spec itself to improve the completeness and
>efficiency of the information it contains.  This should improve the
>debugging experience by making the DWARF itself a richer information
>source, to the extent that it can describe more of what happened to the
>original program; also hopefully any efficiency improvements will allow the
>debugger to be more responsive.
>   1. This is obviously about DWARF itself, although to some extent
>   how we go about generating it.
>   2. Take better advantage of ranges and the .debug_addr table.
>   dblaikie and clayborg have put up ideas about this.
>   3. Figure out a way to allow tracking multiple source locations for
>   an individual instruction.  Right now we mostly give up and set 
> locations
>   to line-0 when this happens.
>   4. Understand the competing needs of profiling and debugging
>   consumers, and see what might be doable there.  (Although this might be
>   tough enough to be its own topic.)
>4. Debug-info testing/validation.  How do we decide what is
>“correct”?
>   1. What are the tools we have, what are they good/bad at, what’s
>   missing?
>
>
>
> I hear that round-tables can be proposed for either ~half hour or ~full
> hour, so with more focused topics we might rather have shorter sessions?
>
>
>
> Thanks,
>
> --paulr
>
>
>
> *From:* llvm-dev  *On Behalf Of *Eric
> Christopher via llvm-dev
> *Sent:* Tuesday, September 22, 2020 2:42 PM
> *To:* Cazalet-Hyams, Orlando ; LLDB Dev <
> lldb-dev@lists.llvm.org>
> *Cc:* llvm-...@lists.llvm.org
> *Subject:* Re: [llvm-dev] Optimised-code debugging experience Round Table
>
>
>
> +LLDB Dev 
>
>
>
> I'll sign up. :)
>
>
>
> My particular interests are:
>
>
>
> - Og (and O1 as Og)
>
> - Correctness testing tools
>
>
>
> Past that the rest of your list seems quite specific, but the overall
> "line tables" and "variable locations" are important.
>
>
>
> Relatedly we have a number of DWARF committee members in llvm and another
> possible discussion area could be: "what extensions do debug info consumers
> think should happen to make dwarf a better input into debugging".
>
>
>
> Thanks.
>
>
>
> -eric
>
>
>
>
>
> On Tue, Sep 22, 2020 at 8:43 AM Cazalet-Hyams, Orlando via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
> Hi all,
>
>
>
> I haven't seen a proposal for an optimised-code debugging experience Round
> Table yet so here goes!
>
> Please let me know if you are interested by emailing me at:
>
>
>
> orlando.hy...@sony.com
>
>
>
> Below is a non-exhaustive list of possible topics. Feel free to include
> any preferences and
>
> suggestions in your response.
>
>
>
>   a. Line tables:
>
> 1. Can we fix is_stmt?
>
> 2. Is prologue_end reliable?
>
> 3. General stepping 

Re: [lldb-dev] [llvm-dev] Optimised-code debugging experience Round Table

[Eric Christopher via lldb-dev]

+LLDB Dev 

I'll sign up. :)

My particular interests are:

- Og (and O1 as Og)
- Correctness testing tools

Past that the rest of your list seems quite specific, but the overall "line
tables" and "variable locations" are important.

Relatedly we have a number of DWARF committee members in llvm and another
possible discussion area could be: "what extensions do debug info consumers
think should happen to make dwarf a better input into debugging".

Thanks.

-eric


On Tue, Sep 22, 2020 at 8:43 AM Cazalet-Hyams, Orlando via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Hi all,
>
>
>
> I haven't seen a proposal for an optimised-code debugging experience Round
> Table yet so here goes!
>
> Please let me know if you are interested by emailing me at:
>
>
>
> orlando.hy...@sony.com
>
>
>
> Below is a non-exhaustive list of possible topics. Feel free to include
> any preferences and
>
> suggestions in your response.
>
>
>
>   a. Line tables:
>
> 1. Can we fix is_stmt?
>
> 2. Is prologue_end reliable?
>
> 3. General stepping behaviour/quality.
>
>
>
>   b. Variable locations:
>
> 1. The state of DW_OP_entry_values in llvm.
>
> 2. The state of the instruction-referencing DBG_VALUE work.
>
> 3. The state of multi-register DWARF expressions in llvm.
>
> 4. The possibility of salvaging out-of-liveness values using the 3
> projects mentioned above.
>
> 5. Floating point debug-info quality in llvm.
>
> 6. Loop induction variable locations.
>
>
>
>   c. Testing debug-info:
>
> 1. Variable correctness testing tools.
>
> 2. Location coverage testing tools.
>
>
>
>   d. The state of -Og.
>
>
>
> Please respond before Friday (25th) if you are interested as that is the
> submission deadline.
>
>
>
> Thanks,
>
> Orlando
> ___
> 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] HTTP library in LLVM

[Eric Christopher via lldb-dev]

+LLDB Dev  as well for visibility. +Pavel Labath
 since he and I have talked about such things.

On Mon, Aug 31, 2020 at 7:26 PM David Blaikie  wrote:

> [+debug info folks, just as FYI - since the immediate question's more
> about 3rd party library deps than the nuances of DWARF, etc]
>
> I'd imagine avoiding writing such a thing from scratch would be desirable,
> but that the decision might depend somewhat on what libraries out there
> you/we would consider including, what their licenses and further
> dependencies are.
>
> On Mon, Aug 31, 2020 at 4:22 PM Petr Hosek via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> We're considering implementing [debuginfod](
>> https://sourceware.org/elfutils/Debuginfod.html) library in LLVM.
>> Initially, we'd like to start with the client implementation, which would
>> enable debuginfod support in tools like llvm-symbolizer, but later we'd
>> also like to provide LLVM-based debuginfod server implementation.
>>
>> debuginfod uses HTTP and so we need an HTTP library, ideally one that
>> supports both client and server.
>>
>> The question is, would it be acceptable to use an existing C++ HTTP
>> library or would it be preferred to implement an HTTP library in LLVM from
>> scratch?
>> ___
>> 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: Release process changes

[Eric Christopher via lldb-dev]

This set of changes sounds good to me. Thanks!

-eric

On Thu, May 21, 2020 at 12:00 PM Tom Stellard via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Hi,
>
> I would like to propose a few changes to the LLVM release process.  The
> current process is documented here:
> https://llvm.org/docs/HowToReleaseLLVM.html
>
> There are two parts to this proposal.  The first is a list of
> clarifications,
> which are things we are currently doing that aren't documented. The second
> is a list of changes which would actually modify how releases are currently
> managed.
>
>
>
> *** Proposed Clarifications ***
>
>
>
> **  Release manager is allowed to commit changes to the release branch
> without
> code owner approval.  However, the release manager is encouraged to
> consult
> with code owners or patch reviewers for non-trivial changes.
>
> It's not practical to get code owner approval every time.  Either because
> there
> is no code owner or because the number of backports is too high (e.g.
> pre-rc1 / pre-rc2).
> This proposed clarification matches how releases are currently managed.
>
>
> ** There is no official release criteria.
>
> We have time-based releases and when the release is 'ready' has been
> up to the discretion of the release manager.  Changing the release
> criteria is out of the scope of this proposal, but I do think it would
> be good to have a discussion about this as a community, so I'm going to
> start a separate thread to discuss this.
>
>
>
> *** Proposed Changes ***
>
>
>
> ** Create a time-based bug-fix release schedule.  After each major
> release, make
>a new bug-fix release every 2 weeks for 12 weeks (6 releases total).
>
> ** Eliminate release candidates for bug-fix releases.
>
> The current unofficial bug-fix release schedule is:
>
> X.Y.1-rc1 (6 weeks after major release)
> X.Y.1-rc2 (10 weeks after major release)
> X.Y.1-final (12 weeks after major release)
>
> I think this change will improve the overall test coverage of the release
> branch.
> I don't think the branch itself or even the release candidates get the same
> level of testing as the final releases.  If we are consistently
> snapshotting
> the release branch and putting out releases, I think this will make it
> easier
> and thus more likely that users will test out the release branch code.
>
> Additionally, with more frequent bug-fix release it removes the need to
> have
> release candidate releases. Every bug-fix release (up until the last one)
> would serve the same purpose as our current release candidates in that they
> are intended to give users an easier way to test the code before the final
> release.
>
>
> ** Create clear rules for what kind of backports are accepted during each
>release phase.
>
> * Before RC1:Patches should be limited to bug fixes, important optimization
>   improvements, or completion of features that were started before the
> branch
>   was created.  As with all phases, release managers and code owners can
> reject
>   patches that are deemed too invasive.
>
> * Before RC2: Patches should be limited to bug fixes or backend specific
>   improvements that are determined to be very safe.
>
> * Before RC3/Final: Major Release* Patches should be limited to critical
>   bugs or regressions.
>
> * Bug fix releases: Patches should be limited to bug fixes or very safe
>   and critical performance improvements.  Patches must maintain both API
> and
>   ABI compatibility with the previous major release.
>
> * Final bug fix release: Patches should be limited to critical bug fixes
> only.
>
>
>
> What does everyone thing about these changes?
>
>
> -Tom
>
> ___
> 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] Pre-merge lldb testing

[Eric Christopher via lldb-dev]

On Sat, May 16, 2020 at 12:18 PM Greg Clayton  wrote:

>
>
> On May 15, 2020, at 7:04 PM, Eric Christopher via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi All,
>
> We've been testing[1] a number of patches upstream by default via some
> pre-merge checks in phabricator. I was thinking of turning them on for lldb
> as well. Mostly it well just help people know whether or not they've broken
> lldb before they commit something, but won't stop committing or do anything
> else that direction.
>
>
> I am all for it!
>
> Let me know what you think and otherwise I'd like to turn it on in a week
> or so. This will also help keep the test suite a little cleaner on linux
> FWIW.
>
>
> Please do.
>
> There are a few additional links down below and if you have any questions
> send them my way.
>
>
> Will the lldb tests be run automagically if and only if lldb code is
> modified in the patch?
>

I don't think our dependencies in cmake are that good for tests ...
especially since lldb uses a largeish chunk of clang and llvm anyhow :)

-eric



> Thanks!
>
> -eric
>
>
> [1]
> https://github.com/google/llvm-premerge-checks/blob/master/docs/user_doc.md
> [2] https://reviews.llvm.org/project/members/78/
> [3] https://github.com/google/llvm-premerge-checks/issues
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Pre-merge lldb testing

[Eric Christopher via lldb-dev]

Hi All,

We've been testing[1] a number of patches upstream by default via some
pre-merge checks in phabricator. I was thinking of turning them on for lldb
as well. Mostly it well just help people know whether or not they've broken
lldb before they commit something, but won't stop committing or do anything
else that direction.

Let me know what you think and otherwise I'd like to turn it on in a week
or so. This will also help keep the test suite a little cleaner on linux
FWIW.

There are a few additional links down below and if you have any questions
send them my way.

Thanks!

-eric


[1]
https://github.com/google/llvm-premerge-checks/blob/master/docs/user_doc.md
[2] https://reviews.llvm.org/project/members/78/
[3] https://github.com/google/llvm-premerge-checks/issues
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] December LLVM bay-area social is this Thursday!

[Eric Christopher via lldb-dev]

Yep!

On Tue, Dec 31, 2019 at 5:53 PM George Burgess IV via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> Thank you all!
>
> To clarify, a booking with Steins has already been made, yeah?
>
> George
>
> On Mon, Dec 30, 2019 at 10:28 AM Tanya Lattner via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> In case Steins doesn't work out.. BJs in Cupertino has a large space for
>> groups but that would mean closer to Cupertino area.
>>
>> -Tanya
>>
>> On Dec 28, 2019, at 8:50 PM, Eric Christopher via llvm-dev <
>> llvm-...@lists.llvm.org> wrote:
>>
>> Still a bit of a Twitter thread too. A few more options maybe if we want
>> to move to downtown San Jose.
>>
>> On Sat, Dec 28, 2019, 8:47 PM Chandler Carruth via llvm-dev <
>> llvm-...@lists.llvm.org> wrote:
>>
>>> +1, i'm just glad you're making progress on a promising option!
>>>
>>> On Sat, Dec 28, 2019 at 8:33 PM JF Bastien  wrote:
>>>
 The guy on the phone said that wouldn’t be a problem 路‍♂️
 I hope that stays correct! Ideally we’d have the same deal:
 indeterminate number of people, ordering off the menu. I’ll check with you
 if that’s not the case.


 On Dec 28, 2019, at 7:41 PM, Chandler Carruth 
 wrote:

 
 Mostly worried because we talked to them before and they wanted us to
 buy a banquet menu at  A lot of dollars.

 On Sat, Dec 28, 2019, 19:15 JF Bastien via cfe-dev <
 cfe-...@lists.llvm.org> wrote:

> I reached out to Steins (which is right across the street) to see if
> they can host us. I’ll keep y’all posted, it seemed optimistic in our 
> phone
> chat.
>
>
> On Dec 24, 2019, at 11:06 AM, George Burgess IV via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
> Oof. :(
>
> Offhand, I can’t think of any place in particular. As one might
> imagine, accommodating 50+ people isn’t always super easy for places to 
> do.
>
> Suggestions welcome!
>
> On Tue, Dec 24, 2019 at 10:27 AM Sean Silva 
> wrote:
>
>> It looks like Tied House will be shutting down :( Do we have a
>> replacement venue?
>>
>>
>> https://www.mv-voice.com/blogs/p/2019/12/23/facing-monthslong-closure-due-to-chemical-contamination-mountain-view-brewery-tied-house-calls-it-quits
>>
>>
>> On Wed, Dec 4, 2019 at 12:49 PM George Burgess IV via llvm-dev <
>> llvm-...@lists.llvm.org> wrote:
>>
>>> We'll be at Tied House as usual, starting on Thursday the 5th at 7pm!
>>>
>>> If you can, help us plan and RSVP here:
>>> https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzqbhb
>>>
>>> See everyone there!
>>>
>> ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
 ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}

[Eric Christopher via lldb-dev]

The dependency edges caused by the file means that any time anyone
touches that file everything that depends on it is rebuilt. The way
it's included basically means you're doing a full build any time you
touch it. It's who is depending on this file or any file this file
includes, not the other way around.

If no one is expected to touch it then it's probably ok. It looks like
each of the files (lldb/include/lldb/lldb-*.h) is touched ~ once every
few weeks. Mostly I was looking at the edit-compile-debug cycle of the
person working on the patch. Means about once a month someone working
on a patch has to do a much more significant set of rebuilds than
they'd already have to do because of their patch rather than a much
more minimal set of rebuilds.

As far as having a convenient place to put public headers I do agree,
but I'd probably prefer to see that via autogenerated documentation
rather than a set of forward declarations in a single header.

Anyhow, your mileage may vary. Just giving the thoughts around the
rest of the llvm project :)

-eric

On Wed, May 15, 2019 at 3:13 PM Jim Ingham  wrote:
>
> This is a common header file that specifies either common enums & #defines in 
> lldb, or forward declarations of the common classes in lldb.  They don't 
> depend on any other header files in the system, they just establish the 
> common names you should use.  So the dependency analysis introduced by these 
> files should be trivial - they really don't depend on anything else.  And the 
> only time you change them is when you add a new public type or define to 
> lldb, which doesn't happen very often.
>
> But it is very convenient to have a common global set of names for the public 
> entities in lldb, that can be looked up in one place, etc.  You can't 
> actually USE any of the classes from these header files, so they don't 
> obscure what other source files actually use - one problem with the big mongo 
> "Cocoa.h" header file pattern.  If you want to get the class definition of 
> anything, you have to include the specific .h file for that thing.  This is 
> just a list of forward declarations.  Switching to
>
> I haven't done your experiment, but if "I depend on a header that either 
> includes no other files or straight includes another file" really is a 
> significant burden on the dependency analysis, then I'm not sure this pattern 
> is actually the problem.
>
> Jim
>
> > On May 15, 2019, at 1:55 PM, Eric Christopher  wrote:
> >
> > A couple of perspectives FWIW:
> >
> > a) Header file includes increase overall dependencies which affects
> > incremental rebuild time whenever you touch something. Especially more
> > when that header is included into multiple headers that are then
> > included into an array of translation units
> > b) Having each file contain the forward declarations it needs from the
> > project and no more also will help both compile time and understanding
> > what's used in any particular header.
> >
> > As a related exercise:
> >
> > https://twitter.com/echristo/status/1116609586004316160
> >
> > basically has removing a couple of transitive dependencies saving in
> > excess of 70% of the incremental rebuild time after touching a file.
> > This seems significant. :)
> >
> > -eric
> >
> > On Wed, May 15, 2019 at 10:49 AM Jim Ingham via lldb-dev
> >  wrote:
> >>
> >> This commit makes things look a little cleaner, but do we need any of 
> >> these forward declarations at all?
> >>
> >> Most of these files either directly include lldb-forward.h or get it from 
> >> lldb-types.h or lldb-defines.h (which includes lldb-types.h).  As a 
> >> general practice we've been getting all the lldb_private type forward 
> >> declarations this way rather than cluttering up the .h files with 
> >> individual forward declarations.  If we are going to keep doing it that 
> >> way - which I can't see any reason not to do, then we should just delete 
> >> all these forward defines, right?
> >>
> >> Jim
> >>
> >>
> >>> On May 15, 2019, at 2:15 AM, Fangrui Song via lldb-commits 
> >>>  wrote:
> >>>
> >>> Author: maskray
> >>> Date: Wed May 15 02:15:13 2019
> >>> New Revision: 360757
> >>>
> >>> URL: http://llvm.org/viewvc/llvm-project?rev=360757=rev
> >>> Log:
> >>> Group forward declarations in one namespace lldb_private {}
> >>>
> >>> Modified:
> >>>   lldb/trunk/include/lldb/Core/Address.h
> >>>   lldb/trunk/include/lldb/Core/AddressRange.h
> >>>   lldb/trunk/include/lldb/Core/AddressResolver.h
> >>>   lldb/trunk/include/lldb/Core/AddressResolverFileLine.h
> >>>   lldb/trunk/include/lldb/Core/AddressResolverName.h
> >>>   lldb/trunk/include/lldb/Core/Communication.h
> >>>   lldb/trunk/include/lldb/Core/Debugger.h
> >>>   lldb/trunk/include/lldb/Core/Disassembler.h
> >>>   lldb/trunk/include/lldb/Core/EmulateInstruction.h
> >>>   lldb/trunk/include/lldb/Core/FileLineResolver.h
> >>>   lldb/trunk/include/lldb/Core/FileSpecList.h
> >>>   lldb/trunk/include/lldb/Core/FormatEntity.h
> >>>   

Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}

[Eric Christopher via lldb-dev]

A couple of perspectives FWIW:

a) Header file includes increase overall dependencies which affects
incremental rebuild time whenever you touch something. Especially more
when that header is included into multiple headers that are then
included into an array of translation units
b) Having each file contain the forward declarations it needs from the
project and no more also will help both compile time and understanding
what's used in any particular header.

As a related exercise:

https://twitter.com/echristo/status/1116609586004316160

basically has removing a couple of transitive dependencies saving in
excess of 70% of the incremental rebuild time after touching a file.
This seems significant. :)

-eric

On Wed, May 15, 2019 at 10:49 AM Jim Ingham via lldb-dev
 wrote:
>
> This commit makes things look a little cleaner, but do we need any of these 
> forward declarations at all?
>
> Most of these files either directly include lldb-forward.h or get it from 
> lldb-types.h or lldb-defines.h (which includes lldb-types.h).  As a general 
> practice we've been getting all the lldb_private type forward declarations 
> this way rather than cluttering up the .h files with individual forward 
> declarations.  If we are going to keep doing it that way - which I can't see 
> any reason not to do, then we should just delete all these forward defines, 
> right?
>
> Jim
>
>
> > On May 15, 2019, at 2:15 AM, Fangrui Song via lldb-commits 
> >  wrote:
> >
> > Author: maskray
> > Date: Wed May 15 02:15:13 2019
> > New Revision: 360757
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=360757=rev
> > Log:
> > Group forward declarations in one namespace lldb_private {}
> >
> > Modified:
> >lldb/trunk/include/lldb/Core/Address.h
> >lldb/trunk/include/lldb/Core/AddressRange.h
> >lldb/trunk/include/lldb/Core/AddressResolver.h
> >lldb/trunk/include/lldb/Core/AddressResolverFileLine.h
> >lldb/trunk/include/lldb/Core/AddressResolverName.h
> >lldb/trunk/include/lldb/Core/Communication.h
> >lldb/trunk/include/lldb/Core/Debugger.h
> >lldb/trunk/include/lldb/Core/Disassembler.h
> >lldb/trunk/include/lldb/Core/EmulateInstruction.h
> >lldb/trunk/include/lldb/Core/FileLineResolver.h
> >lldb/trunk/include/lldb/Core/FileSpecList.h
> >lldb/trunk/include/lldb/Core/FormatEntity.h
> >lldb/trunk/include/lldb/Core/Module.h
> >lldb/trunk/include/lldb/Core/ModuleList.h
> >lldb/trunk/include/lldb/Core/Opcode.h
> >lldb/trunk/include/lldb/Core/PluginManager.h
> >lldb/trunk/include/lldb/Core/SearchFilter.h
> >lldb/trunk/include/lldb/Core/Section.h
> >lldb/trunk/include/lldb/Core/SourceManager.h
> >lldb/trunk/include/lldb/Core/StreamAsynchronousIO.h
> >lldb/trunk/include/lldb/Core/UserSettingsController.h
> >lldb/trunk/include/lldb/Core/Value.h
> >lldb/trunk/include/lldb/Core/ValueObject.h
> >lldb/trunk/include/lldb/Core/ValueObjectCast.h
> >lldb/trunk/include/lldb/Core/ValueObjectConstResult.h
> >lldb/trunk/include/lldb/Core/ValueObjectConstResultCast.h
> >lldb/trunk/include/lldb/Core/ValueObjectConstResultChild.h
> >lldb/trunk/include/lldb/Core/ValueObjectConstResultImpl.h
> >lldb/trunk/include/lldb/Core/ValueObjectDynamicValue.h
> >lldb/trunk/include/lldb/Core/ValueObjectList.h
> >lldb/trunk/include/lldb/Core/ValueObjectMemory.h
> >lldb/trunk/include/lldb/Core/ValueObjectRegister.h
> >lldb/trunk/include/lldb/Core/ValueObjectSyntheticFilter.h
> >lldb/trunk/include/lldb/Core/ValueObjectVariable.h
> >lldb/trunk/include/lldb/Target/DynamicLoader.h
> >lldb/trunk/include/lldb/Utility/Broadcaster.h
> >lldb/trunk/include/lldb/Utility/Connection.h
> >lldb/trunk/include/lldb/Utility/DataExtractor.h
> >lldb/trunk/include/lldb/Utility/Event.h
> >lldb/trunk/include/lldb/Utility/JSON.h
> >lldb/trunk/include/lldb/Utility/Listener.h
> >lldb/trunk/include/lldb/Utility/StringList.h
> >lldb/trunk/include/lldb/Utility/StructuredData.h
> >lldb/trunk/include/lldb/Utility/UserID.h
> >
> > Modified: lldb/trunk/include/lldb/Core/Address.h
> > URL: 
> > http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Address.h?rev=360757=360756=360757=diff
> > ==
> > --- lldb/trunk/include/lldb/Core/Address.h (original)
> > +++ lldb/trunk/include/lldb/Core/Address.h Wed May 15 02:15:13 2019
> > @@ -19,36 +19,15 @@
> >
> > namespace lldb_private {
> > class Block;
> > -}
> > -namespace lldb_private {
> > class CompileUnit;
> > -}
> > -namespace lldb_private {
> > class ExecutionContextScope;
> > -}
> > -namespace lldb_private {
> > class Function;
> > -}
> > -namespace lldb_private {
> > class SectionList;
> > -}
> > -namespace lldb_private {
> > class Stream;
> > -}
> > -namespace lldb_private {
> > class Symbol;
> > -}
> > -namespace lldb_private {
> > class SymbolContext;
> > -}
> > -namespace lldb_private {
> > class 

Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

[Eric Christopher via lldb-dev]

Honestly I'm looking forward to GitHub's interface here.

On Tue, Mar 19, 2019, 1:25 PM James Y Knight via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I think we definitely will want to support github PRs, at the very least
> as an _option_, even if we continue running/preferring phabricator.
>
> Github PRs are how everyone who is not already super-involved in the llvm
> project is going to want to contribute changes, and we ought to be as
> welcoming as possible to such users.
>
> On Tue, Mar 19, 2019 at 3:15 PM Roman Lebedev via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> On Tue, Mar 19, 2019 at 10:00 PM Tom Stellard via cfe-dev
>>  wrote:
>> >
>> > Hi,
>> >
>> > I would like to follow up on the previous thread[1], where there was a
>> consensus
>> > to disallow merge commits in the llvm github repository, and start a
>> discussion
>> > about how we should enforce this policy.
>> >
>> > Unfortunately, GitHub does not provide a convenient way to fully
>> enforce this policy.
>> > We can enforce it for pull requests, but not for direct pushes to the
>> master branch,
>> > so we will have to come up with our own solution if we want to
>> completely prevent
>> > merge commits.  I've spent some time looking into this and here are a
>> few
>> > options that I've come up with (If you are a GitHub expert and have
>> other
>> > suggestions, please let us know):
>> >
>> > 1. Have either a status check or use the "Rebase and Merge" policy for
>> pull requests
>> > to disallow merge commits.  Disable direct pushes to the master branch
>> and update the
>> > git-llvm script to create a pull request when a developer does `git
>> llvm push` and
>> > then have it automatically merged if there are no merge commits.
>> >
>> > 2. Enforce no merge commits for pull requests, but sill allow
>> developers to push directly
>> > to master without checking for merge requests.  This is essentially a
>> best effort
>> > approach where we avoid having to implement our own custom work-flow
>> for committing,
>> > while accepting the possibility that someone might accidentally push a
>> merge commit.
>> >
>> > 3. Disable direct pushes to master, don't update the git-llvm script
>> and require all
>> > developers to use pull requests, where this policy will be enforced.
>> >
>> > Which option do you prefer?
>> All these options include at least partial usage of/switch to github pr's.
>> I don't think that was discussed before. (FWIW i'm opposed to that.)
>>
>> Is there a fourth option - ask github whether they could make an exception
>> for LLVM to use server-side hooks? They are available in github
>> enterprise.
>>
>> > -Tom
>> Roman.
>>
>> > [1] http://lists.llvm.org/pipermail/llvm-dev/2019-January/129723.html
>> > ___
>> > cfe-dev mailing list
>> > cfe-...@lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Status of DWARF64 in LLDB

[Eric Christopher via lldb-dev]

On Tue, Mar 12, 2019 at 1:43 PM Jan Kratochvil via lldb-dev
 wrote:
>
> On Mon, 11 Mar 2019 21:25:05 +0100, Jan Kratochvil via lldb-dev wrote:
> > I think it is never needed in real world as long as one uses DWP and/or
> > -fdebug-types-section.  Red Hat is using neither (for DWZ postprocessing) 
> > and
> > so I did hit this limit of unsupported DWARF64 in GNU utilities [attached].
>
> FYI chromium-67.0.3396.87.rpm built with gcc-8.3.1-2.fc29.x86_64 DWARF-4
> -fdebug-types-section has 1.6GB .debug_info and 0.5GB .debug_types:
>
> Section Headers:
>   [Nr] Name   Type Address  Off  Size ES Flg Lk 
> Inf Al
>   [30] .debug_aranges PROGBITS    000360   7a7630 00  0   
> 0 16
>   [31] .debug_infoPROGBITS    7a7990 5e358d47 00  0   
> 0  1
>   [32] .debug_abbrev  PROGBITS  5eb006d7  716d053 00  0   
> 0  1
>   [33] .debug_linePROGBITS  65c6d72a  c686a97 00  0   
> 0  1
>   [34] .debug_str PROGBITS  722f41c1 21c96669 01  MS  0   
> 0  1
>   [35] .debug_loc PROGBITS  93f8a82a 24b3a638 00  0   
> 0  1
>   [36] .debug_ranges  PROGBITS  b8ac4e62  ec29fd0 00  0   
> 0  1
>   [37] .debug_types   PROGBITS  c76eee32 1cab0bd3 00  0   
> 0  1
>
FWIW I would consider Chromium a medium sized project...

I'll see if I can grab some sample numbers of a few internal applications.

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

Re: [lldb-dev] Status of DWARF64 in LLDB

[Eric Christopher via lldb-dev]

On Mon, Mar 11, 2019 at 3:49 PM Adrian Prantl via lldb-dev
 wrote:
>
>
>
> On Mar 11, 2019, at 3:46 PM, Zachary Turner  wrote:
>
> Given that:
>
> 1) LLVM doesn't produce DWARF64
> 2) GCC has to be patched to produce DWARF64
> 3) LLDB's support is only partial but is untested and appears to be missing 
> major pieces in order for it to work
> 4) It's of questionable use as there are several viable alternatives
>
> Would it be reasonable to propose a patch removing the incomplete support 
> from LLDB?  We can always add it back later when someone is ready to really 
> support and test it properly, and the history in the repository will show 
> what code would need to be changed to get back to at least where the support 
> is today (which again, appears to not fully work).
>
> If we can go this route, it makes merging the two DWARF parsing 
> implementations quite a bit simpler
>
>
> I'm supportive of removing DWARF64 support from LLDB.
>

Sounds good to me as well. We may need to add it in the next few
years, but simplifying interfaces for now sounds entirely reasonable.

-eric

> -- adrian
>
>
> On Mon, Mar 11, 2019 at 3:33 PM Adrian Prantl  wrote:
>>
>>
>>
>> > On Mar 11, 2019, at 12:45 PM, Zachary Turner via lldb-dev 
>> >  wrote:
>> >
>> > I want to ask what the status of DWARF64 in LLDB is.  I can tell there's 
>> > some support for it by reading the code, but it seems to have zero test 
>> > coverage so it's not clear to me that anyone depends on it.  For example, 
>> > I know that clang and LLVM will not even generate DWARF64, so if anyone is 
>> > depending on it, they must be debugging programs built with some other 
>> > toolchain.
>>
>> AFAIR, Apple's tools only generate/support DWARF32. After implementing 
>> type-uniquing in dsymutil we didn't see any individual .dSYM bundles that 
>> came even close to the 4GB watermark.
>>
>> >
>> > I'm looking at unifying LLDB's DWARF parser with LLVM's, and this is the 
>> > biggest functional difference I can see.
>> >
>> > Certainly we can improve LLVM's support for consuming DWARF64, but it's a 
>> > question of priorities.  If nobody is actively depending on this, then 
>> > taking a regression here could be on the table and then re-prioritizing 
>> > adding back support in the future if / when we actually need it.
>>
>> -- adrian
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

[Eric Christopher via lldb-dev]

On Wed, Jan 30, 2019 at 12:42 PM David Greene via cfe-dev
 wrote:
>
> Bruce Hoult via llvm-dev  writes:
>
> > How about:
> >
> > Require a rebase, followed by git merge --no-ff
> >
> > This creates a linear history, but with extra null merge commits
> > delimiting each related series of patches.
> >
> > I believe it is compatible with bisect.
> >
> > https://linuxhint.com/git_merge_noff_option/
>
> We've done both and I personally prefer the strict linear history by a
> lot.  It's just much easier to understand a linear history.
>

Agreed. Let's go with option #1.

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

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

[Eric Christopher via lldb-dev]

On Mon, Jun 18, 2018 at 9:57 AM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
>
> > On Jun 18, 2018, at 9:54 AM,  <
> paul.robin...@sony.com> wrote:
> >
> >> Greg wrote:
> >>> Pavel wrote:
> >>> That said, having DWARF be able to represent the template member
> >>> functions in an abstract way also sounds like nice thing to have from
> >>> a debug info format.
> >>
> >> Yes, that would be great, but will require DWARF changes and is much
> more
> >> long term.
> >
> > I'm curious what utility this has, other than tidying up the Clang AST
> > interface part (because you know what templates exist inside the class).
> > I mean, you can't instantiate new functions; and if you're trying to
> > call an existing instance, you have to go find it anyway, in whichever
> > CU it happens to have been instantiated.
> >
> > Feel free to start a new thread if this is straying too far from the
> > discussion that already strayed from the original topic. :-)
>
> I do agree. Probably no one else will want/need this in DWARF except us as
> I don't believe anyone else is re-creating compiler types with DWARF. Not
> that I don't think it is a good idea for debuggers to do as it allows the
> compiler to be used in the debugger. That being said, we should probably
> look for solutions that are better for all DWARF clients or just fix things
> in our debugger.
>
>
Oh, I've seen DWARF used outside of lldb's context to reconstruct types - I
also think it's a fairly legitimate use of debug info. If we can make it
easier to reconstruct the actual program...

-eric


>
> > Thanks,
> > --paulr
> >
>
> ___
> 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] [llvm-dev] Adding DWARF5 accelerator table support to llvm

[Eric Christopher via lldb-dev]

FWIW I'm completely on board with everything Adrian has said in this thread
:)

-eric

On Wed, Jan 17, 2018 at 11:00 AM Adrian Prantl via llvm-dev <
llvm-...@lists.llvm.org> wrote:

>
>
> > On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
> >
> > As mentioned by Adrian in the comment you linked, I too am looking at
> DWARFv5
> > accelerator tables in LLVM.
> >
> > To give you some background: my motivation is that I want to upstream
> support
> > for (Apple style) accelerator tables in llvm-dsymutil,
>
> Some background for the benefit of everyone who may not be aware of the
> genesis of the DWARF v5 accelerator tables:
>
> DWARF v5 accelerator tables are a direct evolution of the "Apple"
> accelerator tables that are implemented in LLVM (after going through the
> standardization process and being reworked/generalized there), so we hope
> that the implementation can at least share some common interfaces with the
> existing Apple accelerator table implementation where this makes sense.
>
> -- adrian
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

[Eric Christopher via lldb-dev]

Got it, thanks!

On Thu, Oct 20, 2016, 2:26 AM Pavel Labath <lab...@google.com> wrote:

> Our buildbot <
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake>
> runs the test suite with a selection of compilers, one of which is
> clang ToT (test3, test4). You should get an email from it if anything
> breaks.
>
> pl
>
> On 20 October 2016 at 00:24, Eric Christopher via lldb-dev
> <lldb-dev@lists.llvm.org> wrote:
> >
> >
> > On Wed, Oct 19, 2016 at 4:21 PM Tim Hammerquist <pen...@gmail.com>
> wrote:
> >>
> >> On Wed, Oct 19, 2016 at 4:09 PM, Eric Christopher <echri...@gmail.com>
> >> wrote:
> >>>
> >>>
> >>> On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist <pen...@gmail.com>
> wrote:
> >>>>
> >>>> I was mistaken.
> >>>>
> >>>> The system toolchain builds stage1 llvm, clang & co.
> >>>> The system toolchain builds lldb containing the llvm/clang/etc bits.
> >>>> The system toolchain builds gtest test programs.
> >>>>
> >>>> The stage1 compiler builds the python test inferiors.
> >>>>
> >>>
> >>> OK, then it sounds like at least some of the test programs are built
> with
> >>> the new compiler? IIRC the python test inferiors here are the programs
> that
> >>> are the meat of the testsuite for lldb yes?
> >>
> >>
> >> Yes, these programs set up an expected state, and the python testsuite
> >> uses the lldb is used to debug these inferiors.
> >>
> >> So it looks like we want two scenarios:
> >>
> >> Scenario 1: build ToT lldb + llvm/clang/etc using Xcode toolchain; build
> >> test programs AND inferiors using Xcode toolchain
> >> Scenario 2: build ToT lldb + llvm/clang/etc using ToT compiler; build
> test
> >> programs AND inferiors using ToT compiler
> >>
> >> Does that sound right?
> >>
> >> S1 is _nearly_ what we have now; it would only require modifying the
> >> python test suite to build inferiors with the system compiler.
> >>
> >
> > I'd think so. It makes sure that current lldb is going to continue to
> work
> > with both new compilers as well as existing compilers and that current
> lldb
> > is buildable with both current compilers and newer compilers.
> >
> > Thanks!
> >
> > -eric
> >
> >>
> >> I can start looking at what's required to start S2. We've got some
> >> hardware coming to make it easier to bring up.
> >>
> >> -Tim
> >>
> >>
> >>> If so, then on check-in we should possibly see some difference on some
> >>> bot if they all use the same general configuration.  I don't have a
> current
> >>> checkout so I don't know if the default -g is used or if it's set to a
> >>> different dwarf level. Currently it looks like clang will use dwarf4 by
> >>> default with -g:
> >>>
> >>> echristo@dzur ~/tmp> ~/builds/build-llvm/bin/clang -c foo.c -o -
> -target
> >>> x86_64-apple-macosx10.11 -g | llvm-dwarfdump - | grep version | grep -v
> >>> clang
> >>> 0x: Compile Unit: length = 0x0037 version = 0x0004
> >>> abbr_offset = 0x addr_size = 0x08 (next unit at 0x003b)
> >>>  version: 2
> >>>
> >>> where the first line is the debug_info header and the second is the
> >>> version in the line table.
> >>>
> >>> Ted/Greg: Relatedly, what brought this up was the vliw aspect with
> >>> maximum_operations_per_instruction - it's being hard coded to 1 here
> and I'm
> >>> not sure how we want to deal with that on hexagon? Currently it'll be
> hard
> >>> set to 1 so line stepping will work as I imagine it currently does.
> That
> >>> said, if we wanted to take advantage of it then that's different.
> Primarily
> >>> I wasn't sure if Ted and folk had a debugger that did take advantage
> of it
> >>> if it was there.
> >>>
> >>> Thanks!
> >>>
> >>> -eric
> >>>
> >>>>
> >>>>
> >>>> On Wed, Oct 19, 2016 at 3:28 PM, Eric Christopher <echri...@gmail.com
> >
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist <pen...@gmail.com>
> 

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

[Eric Christopher via lldb-dev]

On Wed, Oct 19, 2016 at 4:21 PM Tim Hammerquist  wrote:

> On Wed, Oct 19, 2016 at 4:09 PM, Eric Christopher 
> wrote:
>
>
> On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist  wrote:
>
> I was mistaken.
>
> The system toolchain builds stage1 llvm, clang & co.
> The system toolchain builds lldb containing the llvm/clang/etc bits.
> The system toolchain builds gtest test programs.
>
> The stage1 compiler builds the python test inferiors.
>
>
> OK, then it sounds like at least some of the test programs are built with
> the new compiler? IIRC the python test inferiors here are the programs that
> are the meat of the testsuite for lldb yes?
>
>
> Yes, these programs set up an expected state, and the python testsuite
> uses the lldb is used to debug these inferiors.
>
> So it looks like we want two scenarios:
>
> Scenario 1: build ToT lldb + llvm/clang/etc using Xcode toolchain; build
> test programs AND inferiors using Xcode toolchain
> Scenario 2: build ToT lldb + llvm/clang/etc using ToT compiler; build test
> programs AND inferiors using ToT compiler
>
> Does that sound right?
>
> S1 is _nearly_ what we have now; it would only require modifying the
> python test suite to build inferiors with the system compiler.
>
>
I'd think so. It makes sure that current lldb is going to continue to work
with both new compilers as well as existing compilers and that current lldb
is buildable with both current compilers and newer compilers.

Thanks!

-eric


> I can start looking at what's required to start S2. We've got some
> hardware coming to make it easier to bring up.
>
> -Tim
>
>
> If so, then on check-in we should possibly see some difference on some bot
> if they all use the same general configuration.  I don't have a current
> checkout so I don't know if the default -g is used or if it's set to a
> different dwarf level. Currently it looks like clang will use dwarf4 by
> default with -g:
>
> echristo@dzur ~/tmp> ~/builds/build-llvm/bin/clang -c foo.c -o - -target
> x86_64-apple-macosx10.11 -g | llvm-dwarfdump - | grep version | grep -v
> clang
> 0x: Compile Unit: length = 0x0037 version = 0x0004 abbr_offset
> = 0x addr_size = 0x08 (next unit at 0x003b)
>  version: 2
>
> where the first line is the debug_info header and the second is the
> version in the line table.
>
> Ted/Greg: Relatedly, what brought this up was the vliw aspect with 
> maximum_operations_per_instruction
> - it's being hard coded to 1 here and I'm not sure how we want to deal with
> that on hexagon? Currently it'll be hard set to 1 so line stepping will
> work as I imagine it currently does. That said, if we wanted to take
> advantage of it then that's different. Primarily I wasn't sure if Ted and
> folk had a debugger that did take advantage of it if it was there.
>
> Thanks!
>
> -eric
>
>
>
> On Wed, Oct 19, 2016 at 3:28 PM, Eric Christopher 
> wrote:
>
>
>
> On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist  wrote:
>
> The LLDB job in llvm.org will build a stage1 RA with
> llvm+clang+libcxx+compiler-rt using the system compiler, and use the new
> compiler to build lldb.
>
> By default, this is kicked off automatically when a clang stage1 RA is
> successful, but can be manually triggered to build HEAD, or any revision
> desired.
>
> The python test suite (invoked with the xcodebuild target
> lldb-python-test-suite) uses the newly built compiler to build its test
> programs.
>
>
> http://lab.llvm.org:8080/green/job/lldb_build_test/21202/consoleFull#console-section-4
>
> However, the gtest suite (target lldb-gtest) uses the system (Xcode
> toolchain) compiler to build test programs.
>
>
> http://lab.llvm.org:8080/green/job/lldb_build_test/21202/artifact/lldb/test_output.zip
>
>
> This seems like something that should be fixed :)
>
> -eric
>
>
>
> -Tim
>
> On Wed, Oct 19, 2016 at 2:36 PM, Eric Christopher 
> wrote:
>
> From chatting with Tim it sounds like at least one lldb bot uses the ToT
> compiler - we should probably verify that not only does it use that to
> build lldb but uses it for the tests. That'll get us at least some testing
> here.
>
> -eric
>
>
> On Wed, Oct 19, 2016 at 12:55 PM Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I believe we are good, but it would be good to verify via testing once a
> compiler becomes available.
>
> Greg
>
> > On Oct 19, 2016, at 12:19 PM, Ted Woodward via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > This might affect us. Do we handle it correctly?
> >
> > https://reviews.llvm.org/D16697
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> 

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

[Eric Christopher via lldb-dev]

On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist  wrote:

> I was mistaken.
>
> The system toolchain builds stage1 llvm, clang & co.
> The system toolchain builds lldb containing the llvm/clang/etc bits.
> The system toolchain builds gtest test programs.
>
The stage1 compiler builds the python test inferiors.
>
>
OK, then it sounds like at least some of the test programs are built with
the new compiler? IIRC the python test inferiors here are the programs that
are the meat of the testsuite for lldb yes?

If so, then on check-in we should possibly see some difference on some bot
if they all use the same general configuration.  I don't have a current
checkout so I don't know if the default -g is used or if it's set to a
different dwarf level. Currently it looks like clang will use dwarf4 by
default with -g:

echristo@dzur ~/tmp> ~/builds/build-llvm/bin/clang -c foo.c -o - -target
x86_64-apple-macosx10.11 -g | llvm-dwarfdump - | grep version | grep -v
clang
0x: Compile Unit: length = 0x0037 version = 0x0004 abbr_offset
= 0x addr_size = 0x08 (next unit at 0x003b)
 version: 2

where the first line is the debug_info header and the second is the version
in the line table.

Ted/Greg: Relatedly, what brought this up was the vliw aspect with
maximum_operations_per_instruction
- it's being hard coded to 1 here and I'm not sure how we want to deal with
that on hexagon? Currently it'll be hard set to 1 so line stepping will
work as I imagine it currently does. That said, if we wanted to take
advantage of it then that's different. Primarily I wasn't sure if Ted and
folk had a debugger that did take advantage of it if it was there.

Thanks!

-eric


>
> On Wed, Oct 19, 2016 at 3:28 PM, Eric Christopher 
> wrote:
>
>
>
> On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist  wrote:
>
> The LLDB job in llvm.org will build a stage1 RA with
> llvm+clang+libcxx+compiler-rt using the system compiler, and use the new
> compiler to build lldb.
>
> By default, this is kicked off automatically when a clang stage1 RA is
> successful, but can be manually triggered to build HEAD, or any revision
> desired.
>
> The python test suite (invoked with the xcodebuild target
> lldb-python-test-suite) uses the newly built compiler to build its test
> programs.
>
>
> http://lab.llvm.org:8080/green/job/lldb_build_test/21202/consoleFull#console-section-4
>
> However, the gtest suite (target lldb-gtest) uses the system (Xcode
> toolchain) compiler to build test programs.
>
>
> http://lab.llvm.org:8080/green/job/lldb_build_test/21202/artifact/lldb/test_output.zip
>
>
> This seems like something that should be fixed :)
>
> -eric
>
>
>
> -Tim
>
> On Wed, Oct 19, 2016 at 2:36 PM, Eric Christopher 
> wrote:
>
> From chatting with Tim it sounds like at least one lldb bot uses the ToT
> compiler - we should probably verify that not only does it use that to
> build lldb but uses it for the tests. That'll get us at least some testing
> here.
>
> -eric
>
>
> On Wed, Oct 19, 2016 at 12:55 PM Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I believe we are good, but it would be good to verify via testing once a
> compiler becomes available.
>
> Greg
>
> > On Oct 19, 2016, at 12:19 PM, Ted Woodward via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > This might affect us. Do we handle it correctly?
> >
> > https://reviews.llvm.org/D16697
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> >
> > ___
> > 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
>
>
>
>
> --
> Tim 
>
>
>
>
> --
> Tim 
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

[Eric Christopher via lldb-dev]

On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist  wrote:

> The LLDB job in llvm.org will build a stage1 RA with
> llvm+clang+libcxx+compiler-rt using the system compiler, and use the new
> compiler to build lldb.
>
> By default, this is kicked off automatically when a clang stage1 RA is
> successful, but can be manually triggered to build HEAD, or any revision
> desired.
>
> The python test suite (invoked with the xcodebuild target
> lldb-python-test-suite) uses the newly built compiler to build its test
> programs.
>
>
> http://lab.llvm.org:8080/green/job/lldb_build_test/21202/consoleFull#console-section-4
>
> However, the gtest suite (target lldb-gtest) uses the system (Xcode
> toolchain) compiler to build test programs.
>
>
> http://lab.llvm.org:8080/green/job/lldb_build_test/21202/artifact/lldb/test_output.zip
>
>
This seems like something that should be fixed :)

-eric


>
> -Tim
>
> On Wed, Oct 19, 2016 at 2:36 PM, Eric Christopher 
> wrote:
>
> From chatting with Tim it sounds like at least one lldb bot uses the ToT
> compiler - we should probably verify that not only does it use that to
> build lldb but uses it for the tests. That'll get us at least some testing
> here.
>
> -eric
>
>
> On Wed, Oct 19, 2016 at 12:55 PM Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I believe we are good, but it would be good to verify via testing once a
> compiler becomes available.
>
> Greg
>
> > On Oct 19, 2016, at 12:19 PM, Ted Woodward via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > This might affect us. Do we handle it correctly?
> >
> > https://reviews.llvm.org/D16697
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> >
> > ___
> > 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
>
>
>
>
> --
> Tim 
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

[Eric Christopher via lldb-dev]

>From chatting with Tim it sounds like at least one lldb bot uses the ToT
compiler - we should probably verify that not only does it use that to
build lldb but uses it for the tests. That'll get us at least some testing
here.

-eric

On Wed, Oct 19, 2016 at 12:55 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I believe we are good, but it would be good to verify via testing once a
> compiler becomes available.
>
> Greg
>
> > On Oct 19, 2016, at 12:19 PM, Ted Woodward via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > This might affect us. Do we handle it correctly?
> >
> > https://reviews.llvm.org/D16697
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> >
> > ___
> > 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

Re: [lldb-dev] FYI: Landing the initial draft for an LLVM Code of Conduct

[Eric Christopher via lldb-dev]

Thanks a lot for spearheading this and seeing it move forward. It's
absolutely appreciated.

Thank you.

-eric

On Thu, Jun 30, 2016 at 1:23 PM Chandler Carruth via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hello folks,
>
> As mentioned some time ago[1], we’ve had a long (looong) series of
> discussions about establishing a code-of-conduct for the LLVM project as a
> whole over on the llvm-dev thread and the http://reviews.llvm.org/D13741
> code review.
>
> The discussion has largely died down for some time, and towards the end
> there has been pretty wide support for the draft wording we have now. It
> isn’t perfect, and there are still some important questions around forming
> the advisory committee to handle reporting, but I think the wording is at a
> good point of compromise in a challenging area.
>
> Based on the support, I’m going to land the patch that adds the draft. I’m
> hoping this will immediately provide good advice and guidance, and I’m
> hoping to see motion on setting up a reasonable advisory committee and
> resolving any issues around reporting so we can make this an official part
> of the community.
>
> I sending this as a heads up so folks are aware, not to start a new
> discussion thread. There are existing discussion threads[2] on llvm-dev if
> folks want to join in active discussion or we can start fresh ones, but I
> would encourage people to carefully read the discussion that has already
> taken place to avoid revisiting areas that have already been heavily
> discussed.
>
> Also, many thanks to the folks who provided all their opinions on the
> mailing list threads and in person in long discussions about this topic.
>
> Thanks,
> -Chandler
>
> [1]: Prior announcements:
> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html
> http://lists.llvm.org/pipermail/cfe-dev/2015-October/045460.html
> http://lists.llvm.org/pipermail/lldb-dev/2015-October/008530.html
> http://lists.llvm.org/pipermail/openmp-dev/2015-October/000954.html
>
> [2]: Existing threads:
> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html
> http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html
>
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.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] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Eric Christopher via lldb-dev]

On Tue, Jun 28, 2016 at 12:22 PM Rafael Espíndola 
wrote:

> > I think the main issue (besides users asking what's the big change in
> > 4.0, which I agree is not a big problem) is that the bitcode
> > compatibility policy is tied to the major version number.
>
> It is tied in saying we *can* drop compatibility, not that we will. If
> we still support loading 3.0 bitcode when 4.1 ships we just have to
> document that. It just given us the flexibility to drop it in 4.2 if
> we want.
>
>
I don't think this is as obvious as you might think it is. We can happily
drop the "major version equals bitcode compatibility" implicit promise if
we want, but it's been there for a while and will need some messaging as to
the actual promises here and what we'll do to fulfill and what we mean when
we want to change it (will we actually rev the version? not?). I think
Hans's idea for the release is fine and then will let us argue it as much
as we'd like on llvm-dev until we get a proposal that people are happy with.

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

Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Eric Christopher via lldb-dev]

On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> - Original Message -
>> > From: "Hans Wennborg via cfe-dev" 
>> > To: "llvm-dev" , "cfe-dev" <
>> cfe-...@lists.llvm.org>, "LLDB Dev" ,
>> > "openmp-dev (openmp-...@lists.llvm.org)" 
>> > Cc: "r jordans" , "Paul Robinson" <
>> paul_robin...@playstation.sony.com>
>> > Sent: Monday, June 13, 2016 6:54:19 PM
>> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release]
>> Release plan and call for testers)
>> >
>> > Breaking this out into a separate thread since it's kind of a
>> > separate
>> > issue, and to make sure people see it.
>> >
>> > If you have opinions on this, please chime in. I'd like to collect as
>> > many arguments here as possible to make a good decision. The main
>> > contestants are 4.0 and 3.10, and I've seen folks being equally
>> > surprised by both.
>> >
>> > Brain-dump so far:
>> >
>> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
>> > comes after 3.9.
>> >
>> > - There are special bitcode stability rules [1] concerning major
>> > version bumps. 2.0 and 3.0 had major IR changes, but since there
>> > aren't any this time, we should go to 3.10.
>> >
>> > - The bitcode stability rules allow for breakage with major versions,
>> > but it doesn't require it, so 4.0 is fine.
>> >
>> > - But maybe we want to save 4.0 for when we do have a significant IR
>> > change?
>>
>> I think that this is the right approach, and we happen to have a natural
>> forcing function here: opaque pointer types. I think we should increment
>> the major version number when opaque pointer types are here, as it will be
>> a major breaking change, and then we'll have a version 4.0. Until then,
>> unless something else breaking comes up, 3.10 sounds fine to me.
>>
>
> +1, complete agreement.
>

While I'm not sure opaque pointer types are going to increment versions I'm
also in agreement that 3.10 is the right way to go.

-eric


> ___
> 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] [llvm-dev] GitHub anyone?

[Eric Christopher via lldb-dev]

On Fri, Jun 3, 2016, 10:06 PM Chris Lattner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
> > On Jun 2, 2016, at 11:42 AM, via lldb-dev 
> wrote:
> >
> > Yeah, I get that and I actually don't mind keeping a linear history.
> > But we definitely should branch for release.  Given release branches,
> > there are a number of questions and tradeoffs about how to backport
> > changes from master/latest development to a release.  Some of those
> > options break linear history.  This is the kind of workflow stuff we
> > should clarify if possible.
>
> +1 for branching for official llvm.org releases, and each branch should
> have its own linear history (from its branch point).
>
> I don’t think we want people’s random projects and development branches on
> llvm.org.  They can clone to repo off to their own fork on github and do
> what they want there.
>
>
This and Chris's last post summarize my thoughts on the subject here.

I'm largely agnostic on a move to git or not, however, as far as hosting
services I would prefer github to the others just due to the convenience
with other projects hosted there as well.

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

Re: [lldb-dev] google/stable branch on git mirror?

[Eric Christopher via lldb-dev]

We aren't qualifying it on our side so it hasn't gotten a stable/testing
set of branches.

-eric


On Tue, May 3, 2016 at 4:15 AM Tamas Berghammer via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> +Eric Christopher 
>
> Adding Eric as he was the last person merging changes to the google/stable
> branch. As far as I know nobody releases LLDB from that branch so I
> wouldn't rely on it too much (Android Studio release from master) but you
> can gave it a try if you want.
>
> Tamas
>
> On Fri, Apr 29, 2016 at 7:04 PM Jeffrey Pautler via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi all. First post…new to the mailing list.
>>
>>
>>
>> I was looking for the lldb/branches/google/stable/ branch on a git
>> mirror, but was unable to find it. I was specifically looking at
>> http://llvm.org/git/lldb.git, but didn’t see it anywhere else either
>> (github, etc).
>>
>>
>>
>> Is it only available from the svn repo?
>>
>>
>>
>> Would it be useful for anyone else for that branch to be mirrored to the
>> git repo as well?
>>
>>
>>
>> Thanks,
>>
>> Jeff
>>
>>
>>
>>
>>
>>
>> ___
>> 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

Re: [lldb-dev] [BUG] Many lookup failures

[Eric Christopher via lldb-dev]

On Mon, Nov 30, 2015 at 9:41 AM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> So be sure to enable -fno-limit-debug-info to make sure the compiler isn't
> emitting lame debug info.
>
>
Greg cannot be more wrong here. There are some limitations to be aware of
when using limit debug info, but if the debug info exists for the type in
the object and debug info then it's the fault of the debugger.  The
limitations are pretty well defined, which is "if you ship the debug info
for all parts of the project you've just built then it should work just
fine". It isn't clear whether or not this is the case here, but the
compiler isn't "emitting lame debug info". (Also, it's not clear which
compiler you're using anyhow so Greg's advice is doubly bad).

-eric




> If things are still failing, check to see what we think "CG::Node"
> contains by dumping the type info for it:
>
> (lldb) image lookup -t CG::Node
>
> This will print out the complete class definition that we have for
> "CG::Node" including ivars and methods. You should be able to see the
> inheritance structure and you might need to also dump the type info for
> each inherited class.
>
> Compilers have been trying to not output a bunch of debug info and in the
> process they started to omit class info for base classes. So if you have:
>
> class A : public B
> {
> };
>
> where class "B" has all sorts of interesting methods, the debug info will
> often look like:
>
> class B; // Forward declaration for class B
>
> class A : public B
> {
> };
>
> When this happens, we must make class A in a clang::ASTContext in
> DWARFASTParserClang and if "B" is a forward declaration, we can't leave it
> as a forward declaration or clang will assert and kill the debugger, so
> currently we just say "oh well, the compiler gave us lame debug info, and
> clang will crash if we don't fix this, so I am going to pretend we have a
> definition for class B and it contains nothing".
>
> I really don't like that the compiler thinks this is OK to do, but that is
> the reality and we have to deal with it.
>
> So the best thing I can offer it you must use -fno-limit-debug-info when
> compiling to stop the compiler from doing this and things should be back to
> normal for you. If this isn't what is happening, let us know what the
> "image lookup -t" output looks like and we can see what we can do.
>
> Greg Clayton
> > On Nov 25, 2015, at 10:00 AM, Ramkumar Ramachandra via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > Basic things are failing.
> >
> > (lldb) p lhs
> > (CG::VarExpr *) $0 = 0x00010d445ca0
> > (lldb) p lhs->rootStmt()
> > (CG::ExprStmt *) $1 = 0x00010d446290
> > (lldb) p cg_pp_see_it(lhs->rootStmt())
> > (const char *) $2 = 0x00010d448020 "%A = $3;"
> > (lldb) p cg_pp_see_it(def->rootStmt())
> > error: no member named 'rootStmt' in 'CG::Node'
> > error: 1 errors parsing expression
> > (lldb) p cg_pp_see_it(def)
> > error: no matching function for call to 'cg_pp_see_it'
> > note: candidate function not viable: no known conversion from
> > 'CG::Node *' to 'CG_Obj *' for 1st argument
> > error: 1 errors parsing expression
> >
> > It's total junk; why can't it see the inheritance VarExpr -> Node ->
> > CG_Obj? The worst part is that rootStmt() is a function defined on
> > Node!
> >
> > Ram
> > ___
> > 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