This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [gdbserver/patch] Z packet support
- From: Paul Schlie <schlie at comcast dot net>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: Orjan Friberg <orjan dot friberg at axis dot com>,<gdb-patches at sources dot redhat dot com>
- Date: Sun, 30 Jan 2005 14:55:15 -0500
- Subject: Re: [gdbserver/patch] Z packet support
> From: Daniel Jacobowitz <drow@false.org>
>> On Sun, Jan 30, 2005 at 10:57:17AM -0500, Paul Schlie wrote:
>>> 2. Please re-read the comment; it should not be void *. It is also
>>> required that it be harmless for CORE_ADDR to be too large; see
>>> MIPS n32 vs n64.
>> [ Regarding: And while at it, move CORE_ADDR tweak server.h to wherever
>> it likely belongs? (and/or redefine it to void* if more appropriate)? ]
>>
>> - sorry, it simply seemed implied by your own comment on the subject:
>>
>> "CORE_ADDR is always a long long in gdbserver, so your sizeof (addr)
>> probably doesn't work right for 32-bit targets. I guess sizeof
>> (void *) is always right for this, though... at least for the kinds
>> of targets gdbserver supports now."
>>
>> combined with it's own FIXME comment:
>>
>> /* FIXME: This should probably be autoconf'd for. It's an integer type
>> at least the size of a (void *). */
>> typedef long long CORE_ADDR;
>
> See the second sentence? :-) It has to be an integer type, which void
> * is not. CORE_ADDR has to be at least as large as a target address.
- fair enough, missed that; so Orjan's use of sizeof(addr), which is a
CORE_ADDR, is basically correct; assuming the host platform's long long
is long enough as you point out, which seems like a reasonably safe bet?
> When talking back to GDB, we should endeavour to use the actual size of
> a target address, because sometimes 32-bit GDBs will get annoyed when
> they receive 64-bit numbers.
>
>>> 3. There are nowhere near enough exported functions to justify
>>> proliferating headers.
>>
>> - sorry, guess I always considered "proliferating headers" as required
>> a superior alternative to the maintenance problems which proliferating
>> redundant declarations otherwise creates.
>
> I guess I don't understand you. In what way are these declarations
> "redundant"?
(with respect to "redundant", you're likely correct in questioning my use
of that word, as I had mistakenly assumed that many of the declarations
in server.h, also logically appeared in their corresponding source file
headers; as opposed to being disassociated with them.)
where for for example in server.h:
/* Functions from remote-utils.c */
int putpkt (char *buf);
...
where putpkt implementations matching that prototype are defined in both
remote.c and remote-utils.c, but prototyped in remote.h, and server.h;
where it would have seemed simpler and more consistent to declare public
prototypes in the corresponding header files associated with a function's
implementation, which may then be included by source files as required,
thereby establishing a clear dependency, which would seem to help make
file dependency generation, etc. not to mention general clarity affecting
maintainability of the of the sources. (as just an opinion)
> --
> Daniel Jacobowitz