Re: patch 1/2 debuginfod client

2019-11-18 Thread Frank Ch. Eigler
Hi - > > > But since the user won't see the URL generated they might not notice > > > what is really going on. They will just see that something wasn't > > > found, won't they? > > > > Yes, so the only benefit would be the generation of a different error > > message for impossible buildids. > >

[Bug libdw/25173] dwarf_getsrc_die fails for rust code

2019-11-18 Thread jistone at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25173 --- Comment #6 from Josh Stone --- Aha, I thought this was familiar. I guess I should try to implement that aranges change in rustc after all. However, I think elfutils should probably still try to deal without aranges, on par with binutils.

Re: patch 2/2 debuginfod server etc.

2019-11-18 Thread Frank Ch. Eigler
Hi - > > I see where you're going with it, it's a reasonable concern. For now, > > we can consider it covered by the "debuginfod should be given > > trustworthy binaries" general rule. > > This does keep me slightly worried. Even "trustworthy binaries" could > be produced by buggy compilers. T

[Bug libdw/25173] dwarf_getsrc_die fails for rust code

2019-11-18 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=25173 --- Comment #5 from Mark Wielaard --- I suspect this is the same as https://sourceware.org/bugzilla/show_bug.cgi?id=22288 If so then rustc -Cllvm-args=-generate-arange-section should resolve it. -- You are receiving this mail because: You a

[Bug libdw/25173] dwarf_getsrc_die fails for rust code

2019-11-18 Thread jistone at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25173 --- Comment #4 from Josh Stone --- I can also reproduce this with Clang (clang-9.0.0-1.fc31.x86_64), so it seems to be a more general problem with LLVM as the producer. $ bat main.c ───┬──

[Bug libdw/25173] dwarf_getsrc_die fails for rust code

2019-11-18 Thread jistone at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25173 Josh Stone changed: What|Removed |Added CC||jistone at redhat dot com --- Comment #3

Re: patch 1/2 debuginfod client

2019-11-18 Thread Mark Wielaard
Hi, On Sat, 2019-11-16 at 13:52 -0500, Frank Ch. Eigler wrote: > Yeah, maybe a different automake version made it work after my earlier > failing tests. (dead horse PS. It remains my opinion that we should > commit auto* generated files into git.) > > > > Possible, but since these bits are just

Re: patch 5 debuginfod: prometheus metrics

2019-11-18 Thread Frank Ch. Eigler
Hi - > > > see it is already in a comment in the code. Best to also add it as See > > > also in the docs. > > > > OK. > > Thanks, that would be good. Done. > > > > +control. The \fI/metrics\fP webapi endpoint is probably not > > > > +appropriate for disclosure to the public. > > > > > > So,

Re: patch 4 debuginfod: symlink following mode

2019-11-18 Thread Mark Wielaard
Hi, On Fri, 2019-11-15 at 13:31 -0500, Frank Ch. Eigler wrote: > > > In order to support file/rpm archives that are organized via symlink > > > trees, add an "-L" option to debuginfod, meaning about the same as for > > > find(1) or ls(1): to traverse rather than ignore symlinks. > > > > Could you

Re: patch 5 debuginfod: prometheus metrics

2019-11-18 Thread Mark Wielaard
Hi, On Fri, 2019-11-15 at 12:57 -0500, Frank Ch. Eigler wrote: > Could you also add a reference to the Prometheus Exposition format. I > > see it is already in a comment in the code. Best to also add it as See > > also in the docs. > > OK. Thanks, that would be good. > > > +control. The \fI/me

Re: patch 2/2 debuginfod server etc.

2019-11-18 Thread Frank Ch. Eigler
Hi - > Now that we have the metrics maybe we can poll those to see if the new > files have been indexed? Sort of indirectly. But then we're back to polling, which itself needs a timeout, so the logic is made at least as complicated. > The reason I am complaining about this, is that make check

Re: patch 2/2 debuginfod server etc.

2019-11-18 Thread Mark Wielaard
Hi, On Fri, 2019-11-15 at 14:54 -0500, Frank Ch. Eigler wrote: > > > +set -x > > > > Is this really necessary? > > It makes the log files very verbose. > > Or is that the intention? > > I've found it tricky to debug failing tests without this. OK, but note that you can place echo "starting phas

Re: patch 2/2 debuginfod server etc.

2019-11-18 Thread Mark Wielaard
Hi Frank, On Fri, 2019-11-15 at 16:00 -0500, Frank Ch. Eigler wrote: > > > + string popen_cmd = string("/usr/bin/rpm2cpio " + > > > shell_escape(b_source0)); > > > > Why the hardcoded path? > > Could you check at startup if rpm2cpio is in the PATH? > > Hm, since this is run under popen(), so it

Re: patch 2/2 debuginfod server etc.

2019-11-18 Thread Mark Wielaard
Hi, On Thu, 2019-11-14 at 07:29 -0500, Frank Ch. Eigler wrote: > > > -bin_PROGRAMS = debuginfod-find > > > +bin_PROGRAMS = debuginfod debuginfod-find > > > +debuginfod_SOURCES = debuginfod.cxx > > > +debuginfod_cxx_CXXFLAGS = -Wno-unused-functions > > > > Should that be debuginfod_CXXFLAGS? > > W

Re: patch 3/3 debuginfod client interruptability

2019-11-18 Thread Pedro Alves
On 11/18/19 2:50 AM, Frank Ch. Eigler wrote: >> Attached is a variant that adds debuginfod_begin and debuginfo_end >> (names matching elf/dwarf_begin/end) and adds a debuginfod_client >> handle to each other function. Thanks much for doing this! > > Sure, if you like. Would you be sympathetic t