This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: New gdb 31 & 64 bit patches for S/390
- To: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Subject: Re: New gdb 31 & 64 bit patches for S/390
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Sun, 08 Jul 2001 22:20:54 -0400
- Cc: Denis Joseph Barrow <DJBARROW at de dot ibm dot com>,gdb-patches at sourceware dot cygnus dot com, s390-patches at gnu dot org,Martin Schwidefsky <schwidefsky at de dot ibm dot com>
- References: <Pine.SUN.3.91.1010708105329.24414B-100000@is>
>
> 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