On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard wrote:
> On 12/17/21 16:47, David Blaikie wrote:
> > Sounds pretty good to me - wouldn't mind knowing more about/a good
> summary of the effects of this on project/repo/etc notifications that
> Mehdi's mentioning. (be good to have a write up of the exp
Sounds pretty good to me - wouldn't mind knowing more about/a good summary
of the effects of this on project/repo/etc notifications that Mehdi's
mentioning. (be good to have a write up of the expected impact/options to
then discuss - from the thread so far I understand some general/high level
conce
I haven't made any further progress on it - I think the actual git diff I
posted, changing config.llvm_libs_dir wouldn't quite be shippable as-is,
because it's only correct to add the "/@LLVM_DEFAULT_TARGET_TRIPLE@" if the
runtimes were built with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR ON (which is
the
On Mon, Oct 25, 2021 at 1:28 PM Louis Dionne wrote:
> I believe the issue is probably not related so much to
> LLVM_ENABLE_PROJECTS vs LLVM_ENABLE_RUNTIMES, but rather to the fact that
> LLVM_ENABLE_RUNTIMES uses per-target runtime directories now (hasn't always
> been the case), which basically
+Louis Dionne - perhaps the libcxx and lldb folks would
be interesting in finding a suitable way to address this issue, since
currently either option (using libcxx in ENABLE_PROJECTS or using it in
ENABLE_RUNTIMES) is incomplete - if I use ENABLE_RUNTIMES I get the libcxx
testing run against the j
+lldb-dev
On Mon, Oct 25, 2021 at 9:36 AM Luís Ferreira via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> Hi llvm-dev,
>
> I'm writing here to discuss the addition of D language plugin to LLDB.
> Following the issue #52223 from Bugzilla, we are currently using C/C++
> language plugin for D. This p
On Tue, Oct 19, 2021 at 4:55 PM David Blaikie wrote:
> On Tue, Oct 19, 2021 at 9:08 AM Raphael Isemann
> wrote:
>
>> Actually the RPATH theory is wrong, but the LLVM_ENABLE_PROJECT
>> workaround *should* still work.
>>
>
> I'll give that a go (it's running at the moment) though I guess this is
>
o run these tests
> successfully. I'll either have to get used to ignoring certain failures, or
> disable the tests by not building libcxx in that build tree, which would
> also be unfortunate. (or maybe there's some other workarounds?) Any idea
> how this works for other folks?
> >
r disable the
tests by not building libcxx in that build tree, which would also be
unfortunate. (or maybe there's some other workarounds?) Any idea how this
works for other folks?
- Dave
- Raphael
>
> Am Mo., 18. Okt. 2021 um 05:54 Uhr schrieb David Blaikie via lldb-dev
> :
>
So I'm trying to run a clean "ninja check-lldb" and I'm running into some
difficulties with the libc++ pretty printer tests.
1) They're "unsupported" if my host compiler is gcc:
$ ninja
check-lldb-api-functionalities-data-formatter-data-formatter-stl-libcxx
[2/3] Running lit suite
.../src/lldb/t
Wondering if anyone else has encountered/dealt with debugging lldb test
failures like the one shown at the end of this email ("AssertionError: 10
!= 5" in "test.assertEqual(process.GetState(), lldb.eStateStopped)" while
checking that a breakpoint was reached)
Is there anything that could be done t
On Thu, Oct 7, 2021 at 3:44 PM Renato Golin wrote:
> On Thu, 7 Oct 2021 at 23:16, David Blaikie wrote:
>
>> I don't think diversity necessarily relates to this aspect of managerial
>> structure. Unless we're talking about the less benevolent dictatorships
>> where the authority figures both prov
On Thu, Oct 7, 2021 at 3:02 PM Renato Golin wrote:
> On Thu, 7 Oct 2021 at 22:31, David Blaikie wrote:
>
>> This is how we've always done it so far and it has been working well. At
>>> least most people I know think that this is better than most other
>>> alternatives, including ad-hoc decision
On Thu, Oct 7, 2021 at 2:22 PM Renato Golin via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> On Thu, 7 Oct 2021 at 21:48, Reid Kleckner wrote:
>
>> I want to take the other side here, and say that I appreciate that the
>> board is trying to provide more structure for this decision making process.
>
On Mon, Jun 21, 2021 at 12:53 PM Chris Lattner via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> On Jun 9, 2021, at 10:50 AM, Philip Reames via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
> Specific to the dev lists, I'm very hesitant about moving from mailing
> lists to discourse. Why?
>
> Well,
On Tue, Jun 15, 2021 at 9:50 AM Matt P. Dziubinski wrote:
> On 6/15/2021 18:29, David Blaikie wrote:
> >
> >
> > On Tue, Jun 15, 2021 at 7:40 AM Matt P. Dziubinski via llvm-dev
> > mailto:llvm-...@lists.llvm.org>> wrote:
> >
> > On 6/15/2021 12:58, Aaron Ballman via llvm-dev wrote:
> > >
On Tue, Jun 15, 2021 at 7:40 AM Matt P. Dziubinski via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> On 6/15/2021 12:58, Aaron Ballman via llvm-dev wrote:
> > On Mon, Jun 14, 2021 at 5:41 PM James Y Knight via cfe-dev
> > wrote:
> >>
> >> On Thu, Jun 3, 2021 at 6:19 PM James Y Knight
> wrote:
> >
On Tue, May 18, 2021 at 6:50 AM Krzysztof Parzyszek
wrote:
> Post-commit reviews are conducted, in order of preference, on Phabricator,
>
> This still seems like a change in practice that I'm not in favor of,
> personally - due to the current divergence between email and phab review
> feedback. Y
On Mon, May 17, 2021 at 11:12 AM Krzysztof Parzyszek via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> This is a revision of the previous RFC[1]. This RFC limits the scope to
> pre-commit reviews only.
>
>
>
> *Statement:*
>
> Our current code review policy states[2]:
>
> “Code reviews are conducted
Jonas helped me out here (Thanks!)
Seems I was setting LD_LIBRARY_PATH for, so far as I recall, good reasons
(I have some things installed locally in $HOME/install and I thought
somewhere in the mists of time the executables ($HOME/install/bin) didn't
naturally find some shared libraries in $HOME/
On Linux (Ubuntu) + cmake + ninja, it seems this test isn't testing the
checked-out lldb, but instead running the system (or user-dir, in my case)
installed lldb (see examples at the end of this email)
If I remove the user-dir installed lldb then the test fails differently -
complaining that it ca
Thanks Sri.
I've sent out
https://reviews.llvm.org/D94063 and https://reviews.llvm.org/D94064 for
review, which include fixes for the lldb+ranges-on-subprograms issues I
could find so far.
On Wed, Dec 30, 2020 at 6:53 PM Sriraman Tallam wrote:
>
>
> On Tue, Dec 29, 2020 at 4:44 PM Sriraman Tal
On Wed, Dec 23, 2020 at 7:02 PM Sriraman Tallam wrote:
>
>
> On Wed, Dec 23, 2020 at 4:46 PM David Blaikie wrote:
>
>> Hey folks,
>>
>> So I've been doing some more testing/implementation work on various
>> address pool reduction strategies previously discussed back in January (
>> http://lists.
Hey folks,
So I've been doing some more testing/implementation work on various address
pool reduction strategies previously discussed back in January (
http://lists.llvm.org/pipermail/llvm-dev/2020-January/thread.html#138029 ).
I've committed a -mllvm flag to allow experimenting with the first of
Awesome - thanks for making the plan/getting this underway!
On Fri, Nov 13, 2020 at 3:57 PM Mike Edwards via llvm-dev
wrote:
>
> Hi Everyone,
> Many tech communities, including GitHub and Git, have moved away from term
> “master branch” and replaced it with “main branch” in an
> effort to remove
On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek wrote:
> There are several options, I've looked at couple of them and the one I
> like the most so far is https://github.com/yhirose/cpp-httplib for a few
> reasons:
>
> * It's MIT licensed.
>
I hesitate to get into it on the list, not-a-lawyer, etc. Bu
Generally sounds pretty good to me - only variation on the theme (&
certainly imho dealer's choice at this point - if you/whoever ends up doing
this doesn't like the sound of it, they shouldn't feel they have to do it
this way) - maybe creating blank issues up to the current bugzilla PR
number (& m
All things being equal, I'd prefer Richard Smith's proposal that doesn't
involve needing a new/old numbering scheme, but lets us keep a single
numbering/redirection (& I doubt we need the first 200 bugs in any case -
has anyone referred to bugs that early in the last 5 years, say? But
wouldn't mind
Not having given it deep thought/analysis, nor understanding much of the
GIT infrastructure here, but: Sounds good to me, for whatever that's worth
:)
On Mon, Nov 11, 2019 at 4:32 PM Tom Stellard via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> Hi,
>
> I would like to start using GitHub Actions[1
I think it's a "Cross that bridge when we come to it"
See if manual enforcement is sufficient - if it becomes a real problem
that's too annoying to handle manually/culturally, then assess what sort of
automation/enforcement seems appropriate for the situation we are in at
that time.
On Thu, Oct 1
On Thu, Oct 17, 2019 at 11:17 AM Philip Reames via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> I'm also a strong proponent of not requiring the wrapper.
>
> The linear history piece was important enough to make the cost worth it.
> The extra branches piece really isn't. If someone creates a bran
On Wed, Oct 16, 2019 at 6:05 PM David Greene wrote:
> > I'm inclined to the direction suggested by others that the monorepo is
> > orthogonal to this issue and top level tests might not be the right
> thing.
> >
> > lldb already does end-to-end testing in its tests, for instance.
> >
> > Clang do
On Wed, Oct 16, 2019 at 1:09 PM Roman Lebedev via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> FWIW I'm personally cautiously non-optimistic about this,
> but maybe i'm just not seeing the whole picture of the proposal.
>
> Both checking final asm, and checking more than one layer of abstraction
> f
On Wed, Oct 16, 2019 at 12:54 PM David Greene via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> Renato Golin via Openmp-dev writes:
>
> > But if we have some consensus on doing a clean job, then I would
> > actually like to have that kind of intermediary check (diagnostics,
> > warnings, etc) on mos
On Tue, Oct 15, 2019 at 9:26 PM Mehdi AMINI via llvm-dev <
llvm-...@lists.llvm.org> wrote:
>
>
> On Tue, Oct 15, 2019 at 12:26 PM Hubert Tong via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> On Tue, Oct 15, 2019 at 3:47 AM Marcus Johnson via llvm-dev <
>> llvm-...@lists.llvm.org> wrote:
>>
>>
On Tue, Oct 8, 2019 at 12:46 PM David Greene wrote:
> David Blaikie via Openmp-dev writes:
>
> > I have a bit of concern about this sort of thing - worrying it'll lead to
> > people being less cautious about writing the more isolated tests.
>
> That's a fair concern. Reviewers will still need t
I have a bit of concern about this sort of thing - worrying it'll lead to
people being less cautious about writing the more isolated tests. That
said, clearly there's value in end-to-end testing for all the reasons
you've mentioned (& we do see these problems in practice - recently DWARF
indexing b
Yep, in theory maybe "partial units" could be used to address this - though
any solution that's linker-agnostic will have some size overhead most
likely (like type units) & I've never looked at them closely enough to know
if just saying "partial units" is enough to describe the solution in detail
o
On Mon, Jun 18, 2018 at 9:54 AM 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 requir
How do you handle name lookup for nested classes? They have the same
problem (they don't appear in all definitions) - don't appear in all
descriptions of the outer/parent class. (in theory we could ensure there's
always at least a declaration of the nested class - but we don't even do
that if the n
oh, awesome.
Were you using type units? (I imagine that'd make the situation worse -
since the way clang emits DWARF for a type with a member function template
implicit specialization is to emit the type unit without any mention of
this, and to emit the implicit specialization declaration into the
On Thu, Jun 14, 2018 at 11:24 AM Pavel Labath wrote:
> On Thu, 14 Jun 2018 at 17:58, Greg Clayton wrote:
> >
> >
> >
> > On Jun 14, 2018, at 9:36 AM, Adrian Prantl wrote:
> >
> >
> >
> > On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
> >
> > Thank you
If you end up revisiting the design/representation here - I'd be glad to be
involved. It reminds me of some of the tradeoffs/issues around how even
plain C++ types vary between translation units (eg: member function
template implicit specializations - necessarily different ones can appear
in differ
Nice! Thanks for the update:
re: ObjC: Perhaps debug_names and .apple_objc could be emitted at the same
time to address that issue at least in the short term?
As for size impact, have you tested this with fission and compressed debug
info enabled? (both in terms of whether debug_names is as compr
On Wed, May 31, 2017 at 10:44 AM Matthias Braun via llvm-dev <
llvm-...@lists.llvm.org> wrote:
>
> > On May 31, 2017, at 4:06 AM, Pavel Labath wrote:
> >
> > Thank you all for the pointers. I am going to look at these to see if
> > there is anything that we could reuse, and come back. In the mean
On Mon, Jun 13, 2016 at 5:03 PM, Hal Finkel via cfe-dev <
cfe-...@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"
On Sat, Mar 26, 2016 at 11:31 PM, Jeffrey Tan
wrote:
> Thanks David. I meant to send to lldb maillist, but glad to hear response
> here.
>
> Our binary is built from gcc:
> String dump of section '.comment':
> [ 1] GCC: (GNU) 4.9.x-google 20150123 (prerelease)
>
> Is there any similar flag
On Tue, Dec 1, 2015 at 11:29 AM, Greg Clayton wrote:
> So one other issue with removing debug info from the current binary for
> base classes that are virtual: if the definition for the base class changes
> in libb.so, but liba.so was linked against an older version of class B from
> libb.so, lik
On Mon, Nov 30, 2015 at 6:04 PM, Ramkumar Ramachandra
wrote:
> On Mon, Nov 30, 2015 at 5:42 PM, Greg Clayton wrote:
> > When we debug "a.out" again, we might have recompiled "liba.so", but not
> "libb.so" and when we debug again, we don't need to reload the debug info
> for "libb.so" if it hasn'
On Mon, Nov 30, 2015 at 3:29 PM, Greg Clayton wrote:
>
> > On Nov 30, 2015, at 2:54 PM, David Blaikie wrote:
> >
> >
> >
> > On Mon, Nov 30, 2015 at 2:42 PM, Greg Clayton
> wrote:
> > >
> > > This will print out the complete class definition that we have for
> "CG::Node" including ivars and met
On Mon, Nov 30, 2015 at 2:42 PM, Greg Clayton wrote:
> >
> > 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.
On Mon, Nov 30, 2015 at 1:57 PM, Eric Christopher
wrote:
>
>
> 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 wro
52 matches
Mail list logo
