Re: [Buildroot] [PATCH 2/2] package/gdb: use stat() privided by the system

[Sergio Durigan Junior <sergiodj@redhat.com>]

On Monday, September 10 2018, Rich Felker wrote:

> On Mon, Sep 10, 2018 at 11:20:58PM +0200, Romain Naour wrote:
>> Hi Thomas,
>> 
>> Adding the gdb-patches ml and Rich Felker in Cc.
>> 
>> Le 10/09/2018 à 17:49, Thomas Petazzoni a écrit :
>> > Hello,
>> > 
>> > On Sun,  9 Sep 2018 18:37:50 +0200, Romain Naour wrote:
>> >> Use the same workaround [1] as gnulib use to get the original
>> >> definition of stat. Otherwise with musl toolchains, gnulib try to use
>> >> rpl_stat which is not defined.
>> >>
>> >> Fixes:
>> >> https://gitlab.com/free-electrons/toolchains-builder/-/jobs/95552308
>> >>
>> >> [1] http://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/stat.c?id=c9d72f69bd201a1ab31464d91f234ea1817fe0e1
>> >>
>> >> Signed-off-by: Romain Naour <romain.naour@gmail.com>
>> >> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
>> > 
>> > I am confused by this patch. Why do we need that? The <sys/stat.h> on
>> > my system doesn't test __need_system_sys_stat_h. Is this a workaround
>> > to force gnulib to not provide its own stat() replacement ?
>> > 
>> > Why is gnulib misbehaving here ? We have tons of gnulib related hacks
>> > in gdb.mk, and this start to pile up quite a bit. Why do we have all
>> > those gnulib issues with gdb ? Why not with tons of other packages that
>> > also use gnulib ?
>> 
>> There are too many questions here, I can't answer.
>> There are some (old) hack with coreutils like gl_cv_func_gettimeofday_clobber
>> which is in Buildroot since a long time. I can't tell for every gnulib based
>> packages...
>> 
>> > 
>> >> +Use the same workaround [1] as gnulib use to get the original
>> >> +definition of stat. Otherwise with musl toolchains, gnulib try to use
>> >> +rpl_stat which is not defined.
>> > 
>> > Well rpl_stat() is supposed to be implemented by gnulib. So basically
>> > gnulib tells gdb: please don't use stat() but my rpl_stat() wrapper,
>> > but then gnulib doesn't provide rpl_stat().
>> > 
>> > Any idea what's happening here ?
>> 
>> As far I can tell, the regression has been introduced by this commit:
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2441702a72f324e41a1624dc042b334f375e2d81

This is happening because, before the commit mentioned above,
'common-utils.c' (which gets transformed into 'common-utils-ipa.c'
during the gdbserver build) wasn't calling 'stat'.  It doesn't seem like
a regression; it seems like a hidden problem that was uncovered by the
need of 'stat'.

I don't know why this problem is manifesting only when compiling IPA,
and not when compiling 'common-utils.c' during GDB's/gdbserver's build.

> I'm not aware of all the context, but it looks like different source
> files disagree on whether gnulib has replaced stat or not -- the
> gnulib source file thinks it hasn't, so the rpl_stat function isn't
> defined, but gdb's common-utils-ipa.c file (or rather the gnulib
> stat.h included into it?) thinks it has been replaced and is trying to
> use the replacement. This is likely the result of an incorrect hack
> somewhere. Do you know if it happens with upstream gdb and musl or
> just in buildroot's package?

Haven't really investigated, but be aware that there has been a recent
attempt at updating our local gnulib copy, which unfortunately
introduced a bunch of build failures and had to be reverted (even though
I don't really see how 'stat' could be affected).  I'm not sure if you
are using the latest git HEAD or not (it seems like you aren't, but I
decided to write this anyway); if that's the case, you might want to try
to rebuild with the latest HEAD (I reverted the gnulib update patch
today).

/me thinks a bit more...

I'm thinking here that this is similar to a problem we had recently,
which existed when cross-compiling GDB.  Basically, in this scenario,
gnulib's mechanism to detect cross-compilation was poor and lead to the
unneeded replacement of 'getcwd' in some systems that did have a working
'getcwd', and that was causing problems when running the cross GDB.  The
bug is here:

  https://sourceware.org/bugzilla/show_bug.cgi?id=23558

and the fix was to improve gnulib's machinery and make it a bit smarter
when detecting cross-compilation scenarios.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/