Re: [PATCH] Use sized types in tracepoint.

[Pedro Alves <palves@redhat.com>]

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 <stdint.h>
> lynx-i386-low.c:#include <stdint.h>
> lynx-ppc-low.c:#include <stdint.h>
> thread-db.c:#include <stdint.h>
> tracepoint.c:#include <stdint.h>
> win32-low.c:#include <stdint.h>
> 
> 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 <inttypes.h>
>>>  #if HAVE_STDINT_H
>>        ^^^^^^^^^^^^^
>>>  #include <stdint.h>
>>>  #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