This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: long long considered harmful?
On Wed, Apr 23, 2003 at 09:39:13AM -0400, Kris Warkentin wrote:
> > > Pardon me, by overall structure, I mean the starting address of the
> > > structure. Having a 64 bit entry causes the compiler to align the
> structure
> > > on a 64 bit boundary.
> >
> > Whoever told you this is mistaken. A long long member of a structure
> > only has four byte alignment on i386-linux, for example. That's
> > mandated by the psABI.
> >
> > This is exactly one of those reasons why you can not use structures
> > on the host to describe data on the target.
>
> I'm not talking about host vs. target here. These are the structures used
> by our Mips and PowerPC kernels. I believe the mips compiler will do the
> alignment as mentioned above. You are correct that you can't rely on it
> being the same on host and target but this is not something that matters in
> this case. All that's important is that when the data comes over the wire,
> we can get at it. In this case, because of the awkward define (data below
If you want to get at it, then it _is_ a host vs. target issue.
> is unsigned regs[74]), we wind up extracting the mips registers like so:
>
> static void regset_fetch( int endian, unsigned first, unsigned last,
> unsigned *data )
> {
> if( endian) data += 1; /* data in second word for big endian */
> for(; first <= last; ++first) {
> supply_register(first, (char *)data);
> data+=2;
> }
> }
>
> I know it's not 100% portable. I personally don't really care as long as it
> works on the hosts that we support. The only reason I'm asking all this is
> because I want to know what level of portability is required for the GDB
> project to accept this patch. I was trying to eliminate the long longs in a
> relatively painless way and the char array seems to be not too bad. Are you
> really trying to tell me that gdb wouldn't blow up on a 32 bit char host as
> it stands right now? If you really feel that the only way for me to make
> this acceptable is to just use a blob of memory and a table of offsets into
> it, then that's what I'll do. My mandate is to get our stuff accepted so I
> don't really have a choice. (I'd really rather not though. ;-)
If it's not portable, I'd really strongly prefer it not go in at all
until it is. I went through this exact thing making core dumps work in
a cross environment; someone wanted to use them from a 64-bit Solaris
host.
It's just as easy to do it right, really. Look at this:
typedef char qnx_reg64[8];
static void regset_fetch (int endian, unsigned first, unsigned last, qnx_reg64 *data)
{
for (; first <= last; first++)
{
if (endian)
supply_register (first, (char *) &data[0][4]);
else
supply_register (first, (char *) data);
data++;
}
}
Was that really so hard? And it's a lot clearer.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer