Re: [gdbserver/patch] Z packet support

[Paul Schlie <schlie@comcast.net>]

> 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