Re: New gdb 31 & 64 bit patches for S/390

[Andrew Cagney <ac131313@cygnus.com>]

> 
> If taken at face value, IMHO this is too harsh to the developers.


Even on a host I think it is wrong for GDB to assume that the compiler 
is going to be GCC.  LCC and a few other free compilers come to mind. 
For what its worth, I don't think __attribute__((packeted)) is even 
needed on the host - the ABI should have specified what the packing 
rules were and, hence, guarenteed, the packing.


> I agree that compiler-specific extensions should be kept at the bare
> minimum, but why are you opposed to __attribute__((packed)) in native
> files?  Some functionality is impossible to get right without that.
> How else can I define a struct which fits some external OS data
> structure which is not under my control?  The only way I know of is to
> use a char array with ugly, hand-computed, error-prone offsets into it
> and lots of type casts to fetch and store data there.  Do we really
> want that kind of ugliness in GDB?


FYI, there are two ways of dealing with it: the first (adopted by the 
shlib code) did memory_read()'s to extract the relevant fields from 
target memory.  The second, adopted by C++, uses GDB's `struct type *' 
describe the data structures it needs to read from memory.

enjoy,
	Andrew