[PATCH] libdwfl: Do not dlopen libdebuginfod if DEBUGINFOD_URLS is unset or empty
Avoid calling expensive dlopen at the cost of an extra getenv check when
we already know it would not be needed.
This mirrors the getenv check from debuginfod_query_server.
Signed-off-by: Vitaly Chikunov
Reviewed-by: Dmitry V. Levin
---
libdwfl/debuginfod-client.c | 8
1 file changed, 8 insertions(+)
diff --git a/libdwfl/debuginfod-client.c b/libdwfl/debuginfod-client.c
index ee604ad9..6fd83900 100644
--- a/libdwfl/debuginfod-client.c
+++ b/libdwfl/debuginfod-client.c
@@ -38,6 +38,8 @@ static __typeof__ (debuginfod_find_executable)
*fp_debuginfod_find_executable;
static __typeof__ (debuginfod_find_debuginfo) *fp_debuginfod_find_debuginfo;
static __typeof__ (debuginfod_end) *fp_debuginfod_end;
+static const char *server_urls_envvar = DEBUGINFOD_URLS_ENV_VAR;
+
/* NB: this is slightly thread-unsafe */
static debuginfod_client *
@@ -101,6 +103,12 @@ __libdwfl_debuginfod_end (debuginfod_client *c)
void __attribute__ ((constructor))
__libdwfl_debuginfod_init (void)
{
+ /* Is there any server we can query? If not, don't do any work,
+ * just return. Don't try to dlopen. */
+ char *urls_envvar = getenv(server_urls_envvar);
+ if (urls_envvar == NULL || urls_envvar[0] == '\0')
+return;
+
void *debuginfod_so = dlopen("libdebuginfod-" VERSION ".so", RTLD_LAZY);
if (debuginfod_so == NULL)
--
2.25.4
Will eu-addr2line support debuginfod?
Hi, Is it planned to have eu-addr2line supporting debuginfod? I try to pass '[build-id]@address' (in the same format that eu-stack outputting) without success: # eu-stack -b -p 1 PID 1 - process TID 1: #0 0x7ffa8d4c2886 epoll_wait [c017df57d6194b6479cef409cba575bbaa537c94]@0x7ffa8d3c5000+0xfd886 ... $ export DEBUGINFOD_URLS=... $ eu-addr2line '[c017df57d6194b6479cef409cba575bbaa537c94]@0x7ffa8d3c5000+0xfd886' eu-addr2line: a.out: No such file or directory $ Thanks, ps. Additionally, I think, it would be extra cool to have addr2line request functionality added to debuginfod protocol. For example, to request like: '/buildid/123..DEF/addr2line/@0x7ffa8d3c5000+0xfd886'. Our experiments show, that to generate KDE stack traces via debuginfod requires gigabytes of traffic (downloading uncompressed .debug binary), which is many times more than installing (lzma compressed) -debuginfod .rpm file. Where, several remote addr2line requests would do the job.
eu-strip --reloc-debug-sections-only on linux .debug objects
Hi, Is it safe to run `eu-strip --reloc-debug-sections-only` on Linux kernel .debug files, such as vmlinux.debug and .ko.debug modules? It's really reduces size significantly. Description for .ko in PR#24344 looks good (that it strips linking information that does not needed for the kernel, but effect for vmlinux.debug in unstated), but, I want to be extra sure it's safe to add to our (ALT Linux) packaging system for -debuginfo rpms. Thanks,
Re: eu-strip --reloc-debug-sections-only on linux .debug objects
Mark, On Tue, Dec 08, 2020 at 03:21:12PM +0100, Mark Wielaard wrote: > Hi Vitaly, > > On Mon, 2020-12-07 at 18:59 +0300, Vitaly Chikunov wrote: > > Is it safe to run `eu-strip --reloc-debug-sections-only` on Linux > > kernel > > .debug files, such as vmlinux.debug and .ko.debug modules? > > Yes, it was designed to be used on linux .ko.debug modules. Thanks! > vmlinux.debug itself is a special case though. It does contain > relocation between debug sections, but those are not supposed to be > applied and eu-strip --reloc-debug-sections will normally ignore them > because vmlinux is ET_EXEC. See also this recent discussion: > https://gcc.gnu.org/pipermail/gcc/2020-December/234392.html Yes, if kernel is compiled without CONFIG_X86_NEED_RELOCS `eu-strip --reloc-debug-sections-only` does noting to vmlinux.debug, but if it's compiled with `CONFIG_X86_NEED_RELOCS=y` then `eu-strip --reloc-debug-sections-only` actually reduces vmlinux.debug size (almost twice in my experiments). So, I wonder if we don't touch vmlinux binary would eu-strip --reloc-debug-sections for vmlinux.debug break something somehow in subtle way or it's safe. > > It's really reduces size significantly. Description for .ko in > > PR#24344 looks good (that it strips linking information that does not > > needed for the kernel, but effect for vmlinux.debug in unstated), > > vmlinux itself needs to be handled slightly differently, see the thread > above. But I don't fully understand the effect of --emit-relocs -- > discard-none ld options that the x86_64 kernel uses (it might be > different for other arches). `--emit-relocs --discard-none` pair is only used for x86_64 when CONFIG_X86_NEED_RELOCS is enabled, which is used for KASLR or kdump kernels (AFAIK). So, question is what will happen if we don't touch vmlinux, but strip trivial relocs for vmlinux.debug. Or better just not strip like this (yet). > > but, I > > want to be extra sure it's safe to add to our (ALT Linux) packaging > > system for -debuginfo rpms. > > Upstream rpm comes with find-debuginfo.sh which takes an -r option. > The -r flag says to use eu-strip --reloc-debug-sections. Which the > fedora kernel.spec uses. I will implement this then. Thanks, > > Cheers, > > Mark
debuginfod in ALT linux Ex:Re: Will eu-addr2line support debuginfod?
Hi, On Tue, Dec 01, 2020 at 10:23:30AM -0500, Frank Ch. Eigler wrote: > We could also entertain teaching debuginfod itself to compress on the > fly. It's just a more tricky use of the libmicrohttpd apis. Btw, JFYI, we have in ALT Linux our own debuginfod implementation (two scripts in ruby based on man debuginfod(8) protocol description) since 27 Nov 2020. Maybe it would be useful to know there is alternative implementations too. Thanks,
Re: debuginfod in ALT linux Ex:Re: Will eu-addr2line support debuginfod?
Frank, On Tue, Apr 13, 2021 at 02:22:32PM -0400, Frank Ch. Eigler wrote: > Hi - > > > On Tue, Dec 01, 2020 at 10:23:30AM -0500, Frank Ch. Eigler wrote: > > > We could also entertain teaching debuginfod itself to compress on the > > > fly. It's just a more tricky use of the libmicrohttpd apis. > > > > Btw, JFYI, we have in ALT Linux our own debuginfod implementation (two > > scripts in ruby based on man debuginfod(8) protocol description) since 27 > > Nov 2020. Maybe it would be useful to know there is alternative > > implementations too. > > Sure, would be glad to link to it, if you send us a URL to the docs/code > and/or server itself. Public server https://debuginfod.altlinux.org/ Announcement https://lists.altlinux.org/pipermail/devel/2020-November/212756.html Wiki page that mentions it https://www.altlinux.org/Debuginfo (in Russian). Server code was not intended to be a community project, so the changelog is a bit ashaming in it's tersity and granularity http://git.altlinux.org/people/vt/private/debuginfer.git Thanks,
Re: debuginfod in ALT linux Ex:Re: Will eu-addr2line support debuginfod?
Frank, On Wed, Apr 14, 2021 at 01:10:45PM -0400, Frank Ch. Eigler wrote: > Hi - > > > Public server https://debuginfod.altlinux.org/ > > Announcement > > https://lists.altlinux.org/pipermail/devel/2020-November/212756.html > > Ah neat! Added a link to this onto our project page. Thanks! It may be added to the empty cells, packages "all" and architectures "x86_64, i586, aarch64, armh, ppc64le". Vitaly, > > - FChE
Re: [patch] PR27783: default debuginfod-urls profile rework
Frank, On Thu, Nov 11, 2021 at 12:42:47AM +0300, Dmitry V. Levin wrote: > On Sun, Oct 03, 2021 at 05:33:33PM -0400, Frank Ch. Eigler via Elfutils-devel > wrote: > > commit 0c634f243d266ce8841fd311433d5d79555fabf9 > > Author: Frank Ch. Eigler > > Date: Sun Oct 3 17:04:24 2021 -0400 > > > > PR27783: switch default debuginfod-urls to drop-in style files > > > > Rewrote and commented the /etc/profile.d csh and sh script fragments > > to take the default $DEBUGINFOD_URLS from the union of drop-in files: > > /etc/debuginfod/*.urls. Hand-tested with csh and bash, with > > conditions including no prior $DEBUGINFOD_URLS, nonexistent .urls > > files, multiple entries in .urls files. > [...] > > +# $HOME/.profile* or similar files may first set $DEBUGINFOD_URLS. > > +# If $DEBUGINFOD_URLS is not set there, we set it from system *.url files. > > +# $HOME/.*rc or similar files may then amend $DEBUGINFOD_URLS. > > +# See also [man debuginfod-client-config] for other environment variables > > +# such as $DEBUGINFOD_MAXSIZE, $DEBUGINFOD_MAXTIME, $DEBUGINFOD_PROGRESS. > > + > > +if [ -z "$DEBUGINFOD_URLS" ]; then > > +prefix="@prefix@" > > +debuginfod_urls=`find "@sysconfdir@/debuginfod/" -name '*.urls' | > > xargs cat | tr '\n' ' '` If *.urls file does not contain "\n" at the EOF its url will be concatenated to another without separator making multiple urls invalid. I'd suggest you don't use find (supporting subdirectories, why?) with xargs cat ..., but just `for x in *.urls` cycle. Also, running find, xargs, cat, tr, always (even if there is no urls, you can optimize calling cat with xargs -r) Calling so much binaries on login will slow down login to a loaded box, so 'for' cycle perhaps would be faster. If you still going to use so complicated processing would be beneficial to support commentaries in .urls files too, so people can add some description, or comment out some url (there can be many implied by 'urls' name). Thanks,
