This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Update gnulib to current upstream master


On 08/28/2018 08:59 PM, Sergio Durigan Junior wrote:
> [ Disclaimer: I'm sending the patch gzipped because I'm afraid
> sourceware won't accept a 1.2MB message. ]
> 
> It has been a while since we don't update our gnulib copy against
> their upstream master branch, so I thought I'd propose this patch.  It
> also fixes (at least) one bug reported against GDB:
> 
>   https://sourceware.org/bugzilla/show_bug.cgi?id=23558
> 
> The problem reported there is about the replacement of 'getcwd' when
> cross-compiling GDB.  With our current gnulib copy, the mechanism for
> deciding whether to use the system's 'getcwd' or gnulib's version is
> too simplistic and pessimistic, so when cross-compiling we always end
> up using gnulib's version, which has a limitation: it cannot handle
> the situation when the parent directory doesn't have read permissions.
> 
> This has been reported against upstream gnulib and the fix has been
> pushed here:
> 
>   https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=a96d2e67052c879b1bcc5bc461722beac75fc372
> 
> I regtested this patch on Fedora 28 x86-64, and there were no
> regressions.
> 
> OK?

It is standard practice when updating gnulib to discuss the set of
modules that the exercise brings in due to module dependencies.
If we're now including some more modules, that may mean that
we could eliminate some older host compatibility code from gdb
in favor of gnulib's and list the module dependencies
explicitly in IMPORTED_GNULIB_MODULES in update-gnulib.h.

Conversely, there's a chance that we were depending on some
module that wasn't explicitly listed in IMPORTED_GNULIB_MODULES,
and an update could remove the module by mistake.

Another reason for that is that that are some modules that
are problematic for us (e.g., the one that pulls in Windows's
select replacement), so we need to look out for that, in case
it is pulled in by a dependency.

Also, if there were newer m4 files or m4 files deleted, I think we
we need to update the list in gnulib/Makefile.in (aclocal_m4_deps).

Should we cherry pick the getcwd fix to the 8.2 branch?

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]