Re: [patch 1/2] mingw: update gnulib: prepare the sources

[Pedro Alves <palves at redhat dot com>]

On 03/23/2015 05:08 PM, Jan Kratochvil wrote:
> On Mon, 23 Mar 2015 17:51:44 +0100, Pedro Alves wrote:
>> --- /dev/null
>> +++ b/gdb/common/gdb_sys_time.h
>> @@ -0,0 +1,38 @@
> [...]
>> +#ifndef GDB_SYS_TIME_H
>> +#define GDB_SYS_TIME_H
>> +
>> +#include <sys/time.h>
>> +
>> +/* On MinGW-w64, gnulib's sys/time.h replaces 'struct timeval' and
>> +   gettimeofday with versions that support 64-bit time_t, for POSIX
>> +   compliance.  However, the gettimeofday replacement does not ever
>> +   return time_t values larger than 31-bit, as it simply returns the
>> +   system's gettimeofday's (signed) 32-bit result as (signed) 64-bit.
>> +   Because we don't really need the POSIX compliance, and it ends up
>> +   causing conflicts with other libraries we use that don't use gnulib
>> +   and thus work with the native struct timeval, such as Winsock2's
>> +   native 'select' and libiberty, simply undefine away gnulib's
>> +   replacements.  */
>> +#if GNULIB_defined_struct_timeval
>> +# undef timeval
>> +# undef gettimeofday
>> +#endif
>> +
>> +#endif /* #ifndef GDB_SYS_TIME_H */
> 
> With this header file used for GDB's sources aren't gnulib's .c files compiled
> with incompatible ABI?

Other than rpl_gettimeofday (the gettimeofday replacement):

  gettimeofday.o:0000005a T _rpl_gettimeofday

AFAICS, there's no other use of "struct timeval" or gettimeofday in gnulib's
sources.

So although rpl_gettimeofday is built expecting rpl_timeval as
parameter, given the #undef above, gdb never calls it:

$ x86_64-w64-mingw32-nm -A *.o build-gnulib/import/*.o | grep gettimeofday
event-loop.o:                 U gettimeofday
maint.o:                 U gettimeofday
mi-main.o:                 U gettimeofday
remote-fileio.o:                 U gettimeofday
remote-fileio.o:0000000000001b4b t remote_fileio_func_gettimeofday
symfile.o:                 U gettimeofday
utils.o:                 U gettimeofday
build-gnulib/import/gettimeofday.o:0000000000000000 b .bss
build-gnulib/import/gettimeofday.o:0000000000000000 d .data
build-gnulib/import/gettimeofday.o:0000000000000000 N .debug_abbrev
build-gnulib/import/gettimeofday.o:0000000000000000 N .debug_aranges
build-gnulib/import/gettimeofday.o:0000000000000000 N .debug_frame
build-gnulib/import/gettimeofday.o:0000000000000000 N .debug_info
build-gnulib/import/gettimeofday.o:0000000000000000 N .debug_line
build-gnulib/import/gettimeofday.o:0000000000000000 N .debug_macro
build-gnulib/import/gettimeofday.o:                 U gettimeofday
build-gnulib/import/gettimeofday.o:                 U gmtime
build-gnulib/import/gettimeofday.o:                 U localtime
build-gnulib/import/gettimeofday.o:0000000000000000 d localtime_buffer_addr
build-gnulib/import/gettimeofday.o:0000000000000000 p .pdata
build-gnulib/import/gettimeofday.o:0000000000000000 r .rdata$zzz
build-gnulib/import/gettimeofday.o:0000000000000082 T rpl_gettimeofday
build-gnulib/import/gettimeofday.o:0000000000000041 T rpl_gmtime
build-gnulib/import/gettimeofday.o:0000000000000000 T rpl_localtime
build-gnulib/import/gettimeofday.o:0000000000000000 t .text
build-gnulib/import/gettimeofday.o:0000000000000000 b tm_zero_buffer
build-gnulib/import/gettimeofday.o:0000000000000000 r .xdata


Do you think we still have a problem?

Thanks,
Pedro Alves