From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60159 invoked by alias); 23 Mar 2015 17:25:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 60142 invoked by uid 89); 23 Mar 2015 17:25:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 23 Mar 2015 17:25:18 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 7FEA28EA5B for ; Mon, 23 Mar 2015 17:25:17 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2NHPFGF029357; Mon, 23 Mar 2015 13:25:16 -0400 Message-ID: <55104C7B.9060405@redhat.com> Date: Mon, 23 Mar 2015 17:25:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jan Kratochvil CC: Kai Tietz , gdb-patches@sourceware.org, Corinna Vinschen , Nicholas Clifton Subject: Re: [patch 1/2] mingw: update gnulib: prepare the sources References: <20141222221229.GA30575@host2.jankratochvil.net> <108241234.1319759.1419335690162.JavaMail.zimbra@redhat.com> <20141224222045.GA30482@host2.jankratochvil.net> <551044A0.9070607@redhat.com> <20150323170830.GA8493@host1.jankratochvil.net> In-Reply-To: <20150323170830.GA8493@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00727.txt.bz2 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 >> + >> +/* 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