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: [RFC] Import the rename gnulib module


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


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