similar to: HTTP library in LLVM

+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, etc] > >

On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek via llvm-dev < llvm-dev at lists.llvm.org> 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. > * It supports Linux, macOS and Windows (and presumably other platforms). > * It

Hello, I have only negative experiences with cpp-netlib - I would not recommend it. If the discussion was around only the client part I think libcURL would be the best option since it's available everywhere and is a well maintained library. But as you mention it's only the client part. We use pion (https://github.com/splunk/pion) to build a HTTP server interface, but since it seems

The package elfutils-debuginfod-client is needed for even a minimal install, but it is not available on most mirrors. I suspect some are excluding mirroring debuginfo packages with just a *debuginfo* pattern to rsync, where they should do something like *-debuginfo-*.rpm (which should be good for now as I don't see any package with just "debuginfo" in the name, even in Fedora). The

In short: Perhaps we should switch lld to the bfd-style tombstoning behavior for a release or two, letting users opt-in to testing with the new -1/-2 tombstoning in the interim, before switching to the new tombstone by default (while still having the flag to switch back when users find surprise places that can't handle the new behavior). In long: https://reviews.llvm.org/D81784 and follow-on

Hi, On Tue, 6 Oct 2020 at 18:31, David Blaikie <dblaikie at gmail.com> wrote: > > My 2c would be to push back a bit more on the "let's not have a machine readable format, but instead parse the human readable format" - it seems like that's going to make the human readable format/parsing fairly brittle/hard to change (I mean, having the parser in tree will help, for

As I mentioned in the thread (to many people who don't have time to read the discussions), pushing https://reviews.llvm.org/D84825 restores the original behavior. The same effect as one would get by reverting all related patches. If someone gives me an approval, I'll push it immediately. I already get verbal LGTM from Peter. > With respect I think the "request for changes"

>Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: > >On Fri, Jul 17, 2020 at 12:03 AM Fangrui Song < maskray at google.com > wrote: >> >> Thanks for the write-up! >> >> On 2020-07-16, David Blaikie wrote: >> >In short: Perhaps we should switch lld to the bfd-style tombstoning >> >behavior for a release or

Can we please just revert back to what we had before until the discussion about the desired behaviour and how to get there reaches a conclusion? In particular, I would like to merge that revert to the 11.x branch. At this point in the release process, I'm not keen on taking any patch that changes the behavior to something that hasn't been well tested from sitting in trunk for a while. On

> I still think that we do bfd locs with a decent option to change for at least the current release and sources and then, once we're a little more certain we have everything that might want to parse dwarf (say by working with dwarf-discuss), we can change the default. Given what’s been found, I think Eric/Dave are correct, use bfd behavior by default with an option to do the new thing.

On 2020-07-29, Eric Christopher wrote: >I think the arguments are largely compatibility for software that's already >deployed and can't easily upgrade, and wanting to ensure a larger time >frame for migration with a fallback if things go wrong. A bridge basically >from what we had to where we'd like to be. > >I think we also need to make the change in mainline lld as

Honestly even though I do understand the debug information I'm with you and one reason why I'm pushing for the same reset that you are. There are a lot of threads, it's fairly confusing what has been done where and other than some fairly widespread breakage among early users of lld (i.e. a short time from commit to use) it's unclear what the plan is to roll this out effectively

On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev <iovisor-dev at lists.iovisor.org> wrote: > This same value for EM_BPF is being propagated to glibc, > elfutils, and binutils. great! Can you share the link to glibc and the other patches? > diff --git a/include/llvm/Support/ELF.h b/include/llvm/Support/ELF.h > index 352fd8a..fb8ff71 100644 > ---

Created https://reviews.llvm.org/D84825 to be used for release/11.x I haven't seen a strong argument for changing other .debug_* but in any case I don't want to continue debating on this topic. * .debug_ranges & .debug_loc: -2 (lld<11: 0+addend) * .debug_*: 0 (lld<11: 0+addend, lld HEAD: -1) On Mon, Jul 27, 2020 at 12:47 PM David Blaikie <dblaikie at gmail.com> wrote:

>On Fri, Jul 17, 2020 at 1:55 PM Alexey Lapshin <a.v.lapshin at mail.ru> wrote: >> >> >Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: >> > >> >On Fri, Jul 17, 2020 at 12:03 AM Fangrui Song <maskray at google.com> wrote: >> >> >> >> Thanks for the write-up! >> >> >>

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

>From my understanding the breakpad bug was also only related to .debug_line and has been fixed by https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2317730 > a) .debug_ranges&.debug_loc => -2, .debug_line => 0, other .debug_* -> -1 > b) .debug_ranges&.debug_loc => -2, other .debug_* => 0 I am still of the opinion that we should just do a), not b).

>On Mon, Jul 20, 2020 at 10:32 AM Alexey Lapshin ><alapshin at accesssoftek.com> wrote: >> >> >On Fri, Jul 17, 2020 at 1:55 PM Alexey Lapshin <a.v.lapshin at mail.ru> wrote: >> >> >> >> >Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: >> >> > >> >> >On Fri, Jul 17, 2020 at

On Wed, Aug 5, 2020 at 12:50 PM Fāng-ruì Sòng <maskray at google.com> wrote: > On Wed, Aug 5, 2020 at 12:32 PM Eric Christopher <echristo at gmail.com> > wrote: > > > > Honestly even though I do understand the debug information I'm with you > and one reason why I'm pushing for the same reset that you are. There are a > lot of threads, it's fairly

Hello, I'm taking 7.4 for a spin.? I did the minimal install, and ran into trouble with groupinstall base.? The trouble seems to stem from elfutils.? One command claims elfutils-libs-0.166-2.el7.x86_64 is missing, and another one claims it's installed.? Not sure what's going on here. [root at ip-172-31-34-187 ~]# yum -y install elfutils.x86_64 Loaded plugins: fastestmirror