This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Import the rename gnulib module
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Thu, 30 Oct 2014 12:08:20 +0000
- Subject: Re: [RFC] Import the rename gnulib module
- Authentication-results: sourceware.org; auth=none
- References: <1414628201-12010-1-git-send-email-yao at codesourcery dot com>
On 10/30/2014 12:16 AM, Yao Qi wrote:
> Hi,
> I find the following fails on arm-none-eabi target on mingw32 host.
> The test fileio.exp expects the errno setting on host is in compliance
> with POSIX, however, Windows isn't.
>
> Continuing.^M
> rename 2: ret = -1, errno = 17 EEXIST^M
> ^M
> Breakpoint 2, stop () at fileio.c:76^M
> 76 static void stop () {}^M
> (gdb) FAIL: gdb.base/fileio.exp: Renaming a file to existing directory returns EISDIR
>
> Continuing.^Mv
> rename 4: ret = -1, errno = 17 EEXIST^M
> ^M
> Breakpoint 2, stop () at fileio.c:76^M
> 76 static void stop () {}^M
> (gdb) FAIL: gdb.base/fileio.exp: Renaming a directory to a subdir of itself returns EINVAL
>
> The actual behavior isn't what the msdn doc describes
> <http://msdn.microsoft.com/en-us/library/zw5t957f.aspx>.
>
> In current remote fileio implementation, GDB is expected to behave as
> running on a POSIX system (see https://sourceware.org/gdb/current/onlinedocs/gdb/List-of-Supported-Calls.html),
> this patch is import gnulib rename module to achieve that.
>
> rename is only used in GDB to handle remote fileio request, so I am not
> sure this can justify such huge import. What do you think?
This is bringing in a lot, but it's likely things we'd end up
needing for one reason or another.
The modules this is bringing in likely obsolete some portability
concerns we had before. E.g., this brings in realpath/canonicalize_file_name.
Do we still need gdb_realpath afterwards?
The danger is in gnulib's fallbacks behaving
different from ours, and for some reason, our fallbacks being what
we need.
E.g., this this is bringing in readlink; does is behave the same
as gdbserver's handle_readlink ? If not, is that a problem?
Etc.
(If we end up relying on the dependent gnulib modules, we should
list them s explicit dependencies in gnulib/update-gnulib.sh
though.)
I'd say go ahead if a general audit over what this is bringing
in compared to our own HAVE_foos doesn't show anything
wildly troublesome.
Thanks,
Pedro Alves