* integer types in gdb code
@ 2003-01-27 19:55 Kris Warkentin
2003-01-27 20:40 ` Andrew Cagney
0 siblings, 1 reply; 4+ messages in thread
From: Kris Warkentin @ 2003-01-27 19:55 UTC (permalink / raw)
To: gdb
I'm having trouble cleaning up our code to compile on various targets.
It seems like most targets have uint32_t, int8_t, etc. defined but not
always (ie. cygwin). Is there a 'gdb approved' header or set of defines
that works consistently everywhere? I'd like to be able to use something
consistently in all of our code without having to type in 'unsigned long
long' and such.
cheers,
Kris
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: integer types in gdb code
2003-01-27 19:55 integer types in gdb code Kris Warkentin
@ 2003-01-27 20:40 ` Andrew Cagney
2003-01-27 20:54 ` Kris Warkentin
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2003-01-27 20:40 UTC (permalink / raw)
To: Kris Warkentin; +Cc: gdb
> I'm having trouble cleaning up our code to compile on various targets.
>
> It seems like most targets have uint32_t, int8_t, etc. defined but not
> always (ie. cygwin). Is there a 'gdb approved' header or set of defines
> that works consistently everywhere? I'd like to be able to use something
> consistently in all of our code without having to type in 'unsigned long
> long' and such.
CORE_ADDR ~= void *
LONGEST ~= long
ULONGEST ~= unsigned long
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: integer types in gdb code
2003-01-27 20:40 ` Andrew Cagney
@ 2003-01-27 20:54 ` Kris Warkentin
2003-01-27 21:17 ` Andrew Cagney
0 siblings, 1 reply; 4+ messages in thread
From: Kris Warkentin @ 2003-01-27 20:54 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
> > I'm having trouble cleaning up our code to compile on various targets.
> >
> > It seems like most targets have uint32_t, int8_t, etc. defined but not
> > always (ie. cygwin). Is there a 'gdb approved' header or set of defines
> > that works consistently everywhere? I'd like to be able to use
something
> > consistently in all of our code without having to type in 'unsigned long
> > long' and such.
>
> CORE_ADDR ~= void *
> LONGEST ~= long
> ULONGEST ~= unsigned long
No 16 and 8 bit constructs? Also, what if you want to guarantee the number
of bits? From defs.h it looks to me like LONGEST could be 32 or 64 bits, so
if you're reading structures over the wire, you could have problems.
Kris
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: integer types in gdb code
2003-01-27 20:54 ` Kris Warkentin
@ 2003-01-27 21:17 ` Andrew Cagney
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Cagney @ 2003-01-27 21:17 UTC (permalink / raw)
To: Kris Warkentin; +Cc: gdb
>
>> CORE_ADDR ~= void *
>> LONGEST ~= long
>> ULONGEST ~= unsigned long
>
>
> No 16 and 8 bit constructs? Also, what if you want to guarantee the number
> of bits? From defs.h it looks to me like LONGEST could be 32 or 64 bits, so
> if you're reading structures over the wire, you could have problems.
The above are GDB's host types.
When representing target types (or stuff related to a protocol) GDB can
either use a function like extract_unsigned_integer() or construct a
type exactly describing the data using that (but be wary of byte order
problems).
Trying to do something like:
struct { uint32_t i; ... }
can end up being non-portable (due to struct packing issues and the like).
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-01-27 21:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-27 19:55 integer types in gdb code Kris Warkentin
2003-01-27 20:40 ` Andrew Cagney
2003-01-27 20:54 ` Kris Warkentin
2003-01-27 21:17 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox