From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11699 invoked by alias); 10 Apr 2012 14:17:38 -0000 Received: (qmail 11690 invoked by uid 22791); 10 Apr 2012 14:17:37 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Apr 2012 14:17:14 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3AEH7Xn023893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Apr 2012 10:17:07 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3AEH57k014589; Tue, 10 Apr 2012 10:17:06 -0400 Message-ID: <4F8440E1.40504@redhat.com> Date: Tue, 10 Apr 2012 14:17:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Yao Qi CC: Mark Kettenis , gdb-patches@sourceware.org, Aleksandar Ristovski Subject: Re: [PATCH] Use sized types in tracepoint. References: <1331905618-2631-1-git-send-email-yao@codesourcery.com> <201203161550.q2GFoQhS029855@glazunov.sibelius.xs4all.nl> <4F6362F0.2050906@redhat.com> <4F843CB0.5020302@codesourcery.com> In-Reply-To: <4F843CB0.5020302@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-04/txt/msg00180.txt.bz2 On 04/10/2012 02:59 PM, Yao Qi wrote: > On 03/16/2012 11:57 PM, Pedro Alves wrote: >> On 03/16/2012 03:50 PM, Mark Kettenis wrote: >> >>> We have gnulib/stdint.h so using typedefs like int32_t should be ok. >> >> >> GDBserver doesn't use gnulib, unfortunately. Thought, it looks like >> the Linux, Windows and Lynx backends already unconditionally include stdint.h. >> The NTO backend doesn't, so I'm not sure if we can include it unconditionally. >> > > Unless I miss something, I don't see NTO-backend use stdint.h. > > $ grep stdint *.c *.h > ax.c: be to import stdint.h from gnulib. */ > linux-i386-ipa.c:#include > lynx-i386-low.c:#include > lynx-ppc-low.c:#include > thread-db.c:#include > tracepoint.c:#include > win32-low.c:#include > > tracepoint.c is the only one file using stdint.h conditionally. That's the point. The NTO backend doesn't include stdint.h unconditionally like the others, and the tracepoint.c inclusion is guarded, so we don't know if including stdint.h unconditionally works on NTO. It most probably does. Added Aleksandar to CC. > >> On 03/16/2012 01:46 PM, Yao Qi wrote: >>> +#include >>> #if HAVE_STDINT_H >> ^^^^^^^^^^^^^ >>> #include >>> #endif >> >> So I'd like to see that HAVE_STDINT_H removed first. If this causes >> trouble, the option would be for gdbserver to use gnulib proper. >> > > What kind of trouble you expect to see? Unable to build? I don't expect any real trouble, but yes, that'd be a possibility. > I removed > HAVE_STDINT_H, and successfully build gdbserver on linux, gdbserver on > mingw32, and gdbserver on tic6x-uclinux. Is it qualified as "cause no > trouble"? That was very much already expected, since in all those, stdint.h is already included unconditionally. > In parallel, I am writing a patch to use gnulib in gdbserver. I am not > sure how to place gnulib source tree. We have to choices here, > - Import gnulib separately in gdbserver. We have to gnulib source > trees in gdb and gdbserver respectively, some duplication. However, we > gain some flexibility when gdb and gdbserver wants to import different > modules of gnulib. > - Use gnulib in gdb. Since gnulib is designed as a sub-dir of any > project, if we don't import gnulib in gdbserver, we have to copy gnulib > source to gdbserver source tree during build, and remove it when > finished. Since we have a single source of gnulib, we have to import > any modules that GDB or GDBserver needs. > > Former approach looks better for me. What do you think? I'd prefer to have only one copy of gnulib, until we find a real need to have separate copies. Is it really true that gnulib only works if it is in a direct src subdir? -- Pedro Alves