[PATCH v2 4/3] debuginfod: create libdebuginfod files using a race-free method

Before this change, both the soname and the fully versioned libdebuginfod file name were created after libdebuginfod.so, opening a race for all libdebuginfod users that have Makefile dependencies on libdebuginfod.so but actually use libdebuginfod.so.1 or the fully versioned libdebuginfod file name.

[PATCH v2 3/3] libdwfl: do not fall back to dlopen of libdebuginfod.so

The fully versioned libdebuginfod file name should always be available. Signed-off-by: Dmitry V. Levin --- libdwfl/ChangeLog | 5 + libdwfl/debuginfod-client.c | 3 --- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog index 67a4d7

[PATCH v2 2/3] debuginfod: create the fully versioned libdebuginfod file name during build

When the fully versioned file name is available, the fall back to dlopen of "libdebuginfod.so" in __libdwfl_debuginfod_init is no longer needed. Signed-off-by: Dmitry V. Levin --- debuginfod/ChangeLog | 7 +++ debuginfod/Makefile.am | 10 ++ 2 files changed, 13 insertions(+), 4 de

[PATCH v2 1/3] debuginfod: export DEBUGINFOD_SONAME macro in debuginfod.h

Add DEBUGINFOD_SONAME macro to API for use by those of libdebuginfod clients that would like to dlopen the library in the same way as __libdwfl_debuginfod_init does. Signed-off-by: Dmitry V. Levin --- ChangeLog| 5 + configure.ac

Re: link_map: Remove nested functions

Hi Timm, On Tue, 2020-12-01 at 09:38 +0100, Timm Bäder via Elfutils-devel wrote: > the attached patches get rid of nested functions in > libdwfl/link_map.c. > > I wrote these a while back and just looked at them again and we could > use the same read_state struct here as well. I just quickly chec

Re: [PATCH 3/3] link_map: Inline consider_phdr() into only caller

Hi Timm, On Tue, 2020-12-01 at 09:38 +0100, Timm Bäder via Elfutils-devel wrote: > This gets rid of the tested function and is shorter. It is slightly shorter indeed. Although I changed a couple of lines to not exceed 80 chars. And I added a ChangeLog entry to libdwfl/ChangeLog. Pushed. Mark

Re: [PATCH] debuginfod: export DEBUGINFOD_SONAME macro in debuginfod.h

On Sun, Dec 06, 2020 at 08:32:43AM -0500, Frank Ch. Eigler wrote: > Hi - > > > Thanks, I think libdwfl/debuginfod-client.c should use the versioned name > > only, and it shouldn't fallback to "libdebuginfod.so" as it does now. > > I believe the code falls back to the unversioned soname because on

Re: [PATCH] debuginfod: export DEBUGINFOD_SONAME macro in debuginfod.h

Hi - > Thanks, I think libdwfl/debuginfod-client.c should use the versioned name > only, and it shouldn't fallback to "libdebuginfod.so" as it does now. I believe the code falls back to the unversioned soname because only that is available in the build tree (as opposed to the install tree). - FC

Re: [PATCH 1/3] link_map: Pull release_buffer() into file scope

Hi Timm, On Tue, 2020-12-01 at 09:38 +0100, Timm Bäder via Elfutils-devel wrote: > From: Timm Bäder > > Get rid of another nested function It is missing a ChangeLog entry. > diff --git a/libdwfl/link_map.c b/libdwfl/link_map.c > index 29307c74..5c39c631 100644 > --- a/libdwfl/link_map.c > +++

Re: [PATCH] debuginfod: export DEBUGINFOD_SONAME macro in debuginfod.h

Hi Mark, On Sun, Dec 06, 2020 at 01:06:42PM +0100, Mark Wielaard wrote: > Hi Dmitry, > > On Mon, 2020-11-30 at 09:00 +, Dmitry V. Levin wrote: > > Add DEBUGINFOD_SONAME macro to API for use by those of libdebuginfod > > clients that would like to dlopen the library in the same way as > > __li

Re: [PATCH] debuginfod: export DEBUGINFOD_SONAME macro in debuginfod.h

Hi Dmitry, On Mon, 2020-11-30 at 09:00 +, Dmitry V. Levin wrote: > Add DEBUGINFOD_SONAME macro to API for use by those of libdebuginfod > clients that would like to dlopen the library in the same way as > __libdwfl_debuginfod_init does. I can see how this is useful, but shouldn't libdwfl/debu

Re: [PATCH] Drop $(EXEEXT) suffix from shared libraries

On Mon, 2020-11-30 at 21:35 +0100, Mark Wielaard wrote: > On Mon, Nov 30, 2020 at 08:00:00AM +, Dmitry V. Levin wrote: > > According to GNU Automake documentation [1], $(EXEEXT) is the > > suffix > > that should be used for executables, it is not applicable for > > shared libraries. > > > > [1