Hi Milian,

On Wed, Jul 13, 2022 at 09:36:45PM +0200, Milian Wolff wrote:
> On Mittwoch, 13. Juli 2022 20:20:04 CEST Aaron Merey wrote:
> > There weren't any concerns with the patch so I've gone ahead and merged
> > it as commit a4b1839c3c46.

Yeah, sorry, I should have spoken up on the list not just mumbled
something on irc. My only concern was that I was afraid to pull in
libdebuginfod.h api by default. But you handled to by making
debuginfod_client handle an opaque pointer, which it of course is. So
my worry was unfounded.

But I did just now see it has a typo in libdw.map:

ELFUTILS_0.187 {
  global:
    dwfl_get_debuginfod_client;
} ELFUTILS_0.186;

That should be ELFUTILS_0.188 we already released 0.187.
Also (micro optimazition to prevent a PLT call) the internal calls
should use INTUSE (dwfl_get_debuginfod_client).

I made both changes and added a NEWS entry. See attached.

> I got spammed by a flood of mails from buildbot, but from what I can tell the 
> issues are all unrelated to my patch? Or did I break something? See e.g.:
> 
> [1]: https://builder.sourceware.org/buildbot/#/builders/39/builds/41

Those are unrelated to your patch, but a typo in the buildbot step:
https://sourceware.org/git/?p=builder.git;a=commitdiff;h=cc655e64acb45b2904cb4ce3169c8be92422e2c4;hp=7de05787acb62998c0fbbeec7ee6489700910962

Most builders are now green again:
https://builder.sourceware.org/buildbot/#/builders?tags=elfutils

There is however a new failure because of a new glibc/gcc
fortification on ppc64le and s390x:
https://builder.sourceware.org/buildbot/#/builders/43/builds/41
https://builder.sourceware.org/buildbot/#/builders/55/builds/40

These are also unrelated to your patch. The error is:

In file included from /usr/include/ar.h:22,
                 from ../libelf/libelfP.h:33,
                 from core-file.c:31:
In function ‘pread’,
    inlined from ‘pread_retry’ at ../lib/system.h:188:21,
    inlined from ‘elf_begin_rand’ at core-file.c:86:16,
    inlined from ‘core_file_read_eagerly’ at core-file.c:205:15:
/usr/include/bits/unistd.h:74:10: error: ‘__pread_alias’ writing 58 or more bytes into a region of size 10 overflows the destination [-Werror=stringop-overflow=]
   74 |   return __glibc_fortify (pread, __nbytes, sizeof (char),
      |          ^~~~~~~~~~~~~~~
/usr/include/ar.h: In function ‘core_file_read_eagerly’:
/usr/include/ar.h:41:10: note: destination object ‘ar_size’ of size 10
   41 |     char ar_size[10];           /* File size, in ASCII decimal.  */
      |          ^~~~~~~
/usr/include/bits/unistd.h:50:16: note: in a call to function ‘__pread_alias’ declared with attribute ‘access (write_only, 2, 3)’
   50 | extern ssize_t __REDIRECT (__pread_alias,
      |                ^~~~~~~~~~
cc1: all warnings being treated as errors

That needs investigation. The ar file format is a little odd, those
fields are in (non-zero terminated) ASCII decimal notation. Which
probably confuses the fortification.

Cheers,

Mark