search for: labath

...o emit the implicit specialization declaration into the stub type in the CU (that references the type unit)) Without type units I'd be pretty surprised if you couldn't call the implicit specialization at least from the CU in which it was instantiated. On Thu, Jun 14, 2018 at 11:41 AM Pavel Labath <labath at google.com> wrote: > On Thu, 14 Jun 2018 at 19:29, Pavel Labath <labath at google.com> wrote: > > > > On Thu, 14 Jun 2018 at 19:26, David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > > > > > > On Thu, Jun 14, 2...

On Thu, 14 Jun 2018 at 19:26, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Jun 14, 2018 at 11:24 AM Pavel Labath <labath at google.com> wrote: >> >> On Thu, 14 Jun 2018 at 17:58, Greg Clayton <clayborg at gmail.com> wrote: >> > >> > >> > >> > On Jun 14, 2018, at 9:36 AM, Adrian Prantl <aprantl at apple.com> wrote: >> > >> > &g...

> On Jan 30, 2018, at 7:35 AM, Pavel Labath <labath at google.com> wrote: > > Hello all, > > I am looking for feedback regarding implementation of the case folding > algorithm for .debug_names hashes. > > Unlike the apple tables, the .debug_names hashes are computed from > case-folded names (to enable case-in...

This has been going on since at least Friday too. On Mon, Apr 10, 2017 at 7:45 AM Manuel Klimek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Mon, Apr 10, 2017 at 4:18 PM Pavel Labath <labath at google.com> wrote: > >> Hi all, >> >> phabricator seems to have stopped sending emails. All other functionality >> is ok, it just does not send email notifications of any actions. Does >> anyone know what's the problem? >> >> cheers,...

On 30 January 2018 at 15:41, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Jan 30, 2018, at 7:35 AM, Pavel Labath <labath at google.com> wrote: >> >> Hello all, >> >> I am looking for feedback regarding implementation of the case folding >> algorithm for .debug_names hashes. >> >> Unlike the apple tables, the .debug_names hashes are computed from >> case-fo...

On 28/01/2020 20:37, David Blaikie via llvm-dev wrote: > and one idea I had was to have the DWARFDataExtractor return a new > DWARFDataExtractor that was specifically bounded to the parsed length > for this reason. I think this would be great. In fact, I was getting ready to propose something like that myself. :) FWIW, lldb DataExtractors already support this kind of slicing. pl

+LLDB Dev <lldb-dev at lists.llvm.org> as well for visibility. +Pavel Labath <labath at google.com> since he and I have talked about such things. On Mon, Aug 31, 2020 at 7:26 PM David Blaikie <dblaikie at gmail.com> wrote: > [+debug info folks, just as FYI - since the immediate question's more > about 3rd party library deps than the nuances of DWARF,...

Hello all, I broke the build, but I did not receive any blame email about it. I have a feeling the blame emails are not working. Is anyone experiencing the same thing? Could it be related to the last-week master restart (which seems to have reset build numbers as well)? regards, pl

On June 22, 2017 at 5:51:39 AM, Pavel Labath (labath at google.com) wrote: I don't have any concrete feedback, but: - +1 for removing the "FastDemagler" - If you already construct an AST as a part of your demangling process, would it be possible to export that AST for external consumption somehow? Right now in lldb we sometim...

Thanks, David for updating us. Regarding, mail address, can use anyone{@gmail or @amd}. but sourav0311 at gmail.com works best for me for mailing lists related stuff. Regarding, GDB side of DWARFv5 side of things, we've testing GDB-8.3 WRT DWARFv5 clang and gcc binaries to get better idea of debuggability of clang generated binaries with GDB. Primary motivation being GDB better handling of

Hi all, phabricator seems to have stopped sending emails. All other functionality is ok, it just does not send email notifications of any actions. Does anyone know what's the problem? cheers, pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170410/8ce9ec7c/attachment.html>

r330121 should fix that. Let me know if you still run into any issues. cheers, pl On Mon, 16 Apr 2018 at 12:07, Pavel Labath <labath at google.com> wrote: > Hello Csaba, > Thanks for the heads up. I am the one who wrote that test. I'll look into > that shortly. Sorry about the trouble. > pl > On Mon, 16 Apr 2018 at 11:56, Csaba Raduly via llvm-dev < > llvm-dev at lists.llvm.org> wrote...

...ote, the demangler is a performance bottleneck for lldb. Going to the fast demangler over the system one was a big performance win. Maybe the system demangler is fast enough nowadays, but if it isn't then we can't get rid of the FastDemangler. Jim > On Jun 22, 2017, at 8:08 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > On 22 June 2017 at 15:21, Erik Pilkington <erik.pilkington at gmail.com> wrote: >> >> >> >> On June 22, 2017 at 5:51:39 AM, Pavel Labath (labath at google.com) wrote: >> >> I don't ha...

I've dealt with similar issues on the LLDB side, I think I can help you with this. pl On 6 January 2017 at 09:39, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Thanks for the info. I can reproduce the issue. But because of lack of cmake > knowledge, I don't know how to fix that now. If no one will take a look at > this, I'll investigate it. > > On

On Thu, 14 Jun 2018 at 17:58, Greg Clayton <clayborg at gmail.com> wrote: > > > > On Jun 14, 2018, at 9:36 AM, Adrian Prantl <aprantl at apple.com> wrote: > > > > On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thank you all. I am going to try to reply to all comments in a single email. > > Regarding the .apple_objc idea, I am afraid the situation is not as > simple as just flipping a switch. > > > Jonas is currently worki...

> On Jan 18, 2018, at 7:52 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Thank you for all the responses. Unfortunately I wasn't able to make > any progress on creating the patches today. I'll be sure to add > everyone who expressed interest here to the phabricator diff once I > have them...

Hello all, I am looking for feedback regarding implementation of the case folding algorithm for .debug_names hashes. Unlike the apple tables, the .debug_names hashes are computed from case-folded names (to enable case-insensitive lookups for languages where that makes sense). The dwarf5 document specifies that the case folding should be done according the the "Caseless matching"

...an Prantl via llvm-dev wrote: >> >> >>> On Mar 31, 2020, at 10:55 AM, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> +1 to all that & cc'ing a few of the usual suspects as FYI >>> >>> On Tue, Mar 31, 2020 at 10:36 AM Pavel Labath via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> >>> For me personally, the ability to write/edit syntactically correct dwarf >>> easily is much more important than being able to generate "...

Hello all, In <https://reviews.llvm.org/D41986#977215> it was brought up that there are at least two parties interested in having DWARF5 accelerator tables implemented, so I'm writing this email to see if there's anyone else interested in this topic, and to try to synchronize our efforts. Our interest for this stems from a desire to make dwarf parsing fast on non-apple targets

...ould need something similar for C++. So maybe a possible solution is some sort of section that can specify all of the DIEs related to a class that are not contained in the class hierarchy itself. This would work for Objective C and for C++. Thoughts? Greg > On Jun 15, 2018, at 3:34 AM, Pavel Labath <labath at google.com> wrote: > > I wasn't using type units (those don't work at all right now). > > I've done a bit of digging, and i found this patch > <https://reviews.llvm.org/rL260308> which explicitly disables template > member function parsing (tho...