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 ti
+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
Hi Walter,
I've only done a brief scan of the document but, in general, I'm favorable
of the goals, aim, and approach. Something I think would be good would be
to compare/contrast against rr as an "exploring alternatives" section of
the document. I think the document should also be made available/
+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 imag
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/HowToR
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 ch
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
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:
>
>>
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
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
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.
>
>
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)
>
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 miss
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.
>
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
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 me
rom it if anything
> breaks.
>
> pl
>
> On 20 October 2016 at 00:24, Eric Christopher via lldb-dev
> wrote:
> >
> >
> > On Wed, Oct 19, 2016 at 4:21 PM Tim Hammerquist
> wrote:
> >>
> >> On Wed, Oct 19, 2016 at 4:09 PM, Eric Christopher
&g
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 contai
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
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
> successfu
>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
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
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
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" <
>
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
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
> br
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
27 matches
Mail list logo
