RE: mips structure padding

RE: mips structure padding

[mike stump]

> Date: Wed, 30 Jan 2002 13:28:37 -0800
> From: "Todd Malsbary" <toddm@fullplaymedia.com>
> To: "Eric Christopher" <echristo@redhat.com>, <gcc@gcc.gnu.org>

> i've attached a testcase that i reduced as much as possible from the
> ecos sources.

I cannot tell if it is a bug.  Someone that knows the C++ abi inside
and out would have to comment on it.  It seems like it should be a
bug.  I'd probably file it as a bug report (against the C++ abi),
though, they might reject it later for not being a bug.

I can't help but point out that I don't like your sources.  What is
compatible, is when the same exact text, character for character is
shown to both compilers, certainly that isn't the case in the code you
present.  :-(

RE: mips structure padding

[Todd Malsbary]

> From: Fergus Henderson [mailto:fjh@cs.mu.oz.au]
> Sent: Thursday, January 31, 2002 2:49 AM
> To: Todd Malsbary
> Cc: Eric Christopher; gcc@gcc.gnu.org
> Subject: Re: mips structure padding
> 
> Do you mean that you think it is a bug that the sizes differ?

yes, the size difference is the part that's puzzling me.

> The answer to that is no, it is not a bug, it is a feature.
> 
> Here's a simplified example.

the example makes perfect sense.  the part that still confuses me is
that i found this problem in the ecos sources which are compiled for a
variety of targets with gcc so i assumed that the sizes are the same on
all the different targets they've used and the size difference is just
showing up with the target i'm using.  anyway, thanks to all the people
who helped me out with this.

Todd
 

Re: mips structure padding

[Fergus Henderson]

On 30-Jan-2002, Todd Malsbary <toddm@fullplaymedia.com> wrote:
> i've attached a testcase that i reduced as much as possible from the
> ecos sources.  when the problem occurs, the c structure size is 176
> bytes and the class is 168 bytes.  by setting the define at the top of
> the cpp file, both items are the same size (176).  so it looks like
> making the Cyg_Alarm class a member variable affects how things get
> padded.  
...
> so is this still a bug?  should i go ahead and file a report?

You don't explain what you think the problem is.

Do you mean that you think it is a bug that the sizes differ?
The answer to that is no, it is not a bug, it is a feature.

Here's a simplified example.
You will get different sizes for X1 and X2 in

	struct Y {
		long long l;
		char c1;
	};
	struct X1 {
		struct Y y;
		char c2;
	} x1;
	struct X2 {
		long long l;
		char c1;
		char c2;
	} x2;

`sizeof(struct Y)' needs to be a multiple of the alignment requirements
of `long long', so that the long long member is correctly aligned when
you have an array of struct Y.

In `struct X1', the `y' field needs to occupy
a full `sizeof(struct Y)' bytes, so that doing
`memset(&x1.y, sizeof(struct Y), 0)' won't clobber c2.
This means there will be some padding after c1.
But in `struct X2', there is no padding between c1 and c2.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

RE: mips structure padding

[Todd Malsbary]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

i've attached a testcase that i reduced as much as possible from the
ecos sources.  when the problem occurs, the c structure size is 176
bytes and the class is 168 bytes.  by setting the define at the top of
the cpp file, both items are the same size (176).  so it looks like
making the Cyg_Alarm class a member variable affects how things get
padded.  

here's what i used to compile the test:
mips-r3000-elf-gcc -g structtest.cpp -nostdlib
and i used:
mips-r3000-elf-gdb a.out -nw
to check the sizes.  i'm running cygwin 1.3.6 on a win2k host and using
gcc 3.0.3 and insight 5.1.  

so is this still a bug?  should i go ahead and file a report?

thanks,
Todd

-----Original Message-----
From: Eric Christopher [mailto:echristo@redhat.com]
Sent: Tuesday, January 29, 2002 8:21 PM
To: gcc@gcc.gnu.org
Subject: Re: mips structure padding


> r3000 target.  is this is a bug or a feature?  in either case, what
> would be the recommended fix?  thanks,

Can you provide a testcase?

-eric



-- 
I will not use abbrev.

[-- Attachment #2: structtest.cpp --]
[-- Type: application/octet-stream, Size: 1540 bytes --]

#include "structtest.h"

#define CYG_ALARM_MEMBER 0

class Cyg_Alarm {
public:
    void 		*next;
    void 		*prev;
    void 		*counter;
    void (*alarm)(void *, unsigned int);
    unsigned int 	 data;
    long long 		 trigger;
    long long  		 interval;
    int 		 enabled;

    Cyg_Alarm(void);
};

class Cyg_ThreadTimer {
public:    
#if (CYG_ALARM_MEMBER)
    Cyg_Alarm 	alarm;
#else
    void 		*next;
    void 		*prev;
    void 		*counter;
    void (*alarm)(void *, unsigned int);
    unsigned int 	 data;
    long long 		 trigger;
    long long  		 interval;
    int 		 enabled;    
#endif    
    void 	*thread;
    
    Cyg_ThreadTimer(void);
};

class Cyg_Thread {
public:
    unsigned int 	 stack_base;
    unsigned int 	 stack_size;
    unsigned int 	 stack_limit;
    unsigned int 	 stack_ptr;
    unsigned int 	 entry_point;
    unsigned int 	 entry_data;
    void 		*saved_context;
    void 		*next;
    void 		*prev;
    int 		 priority;
    void 		*queue;
    int 		 mutex_count;
    int 		 original_priority;
    int 		 priority_inherited;
    unsigned int 	 state;
    unsigned int 	 suspend_count;
    unsigned int 	 wakeup_count;
    unsigned int 	 wait_info;
    unsigned short 	 unique_id;
    Cyg_ThreadTimer 	 timer;
    int 		 sleep_reason;
    int 		 wake_reason;
    unsigned int 	 thread_data[6];
    char 		*name;
    void 		*list_next;
    
    
    Cyg_Thread(void);
};

extern "C" {

    void
    _start(void)
    {
    }
    
};

[-- Attachment #3: structtest.h --]
[-- Type: application/octet-stream, Size: 1299 bytes --]

#ifdef __cplusplus
extern "C" {
#endif

struct cyg_alarm {
    void         *next;
    void         *prev;
    void         *counter;
    void (*alarm)(unsigned int, unsigned int);
    unsigned int  data;
    long long     trigger;
    long long     interval;
    unsigned int  enabled;
};
    
struct cyg_threadtimer {
    cyg_alarm  alarm;
    void      *thread;
};
    
struct cyg_thread {
    unsigned int     stack_base;
    unsigned int     stack_size;
    unsigned int     stack_limit;
    unsigned int     stack_ptr;
    unsigned int     entry_point;
    unsigned int     entry_data;
    void            *saved_context;
    void            *next;
    void            *prev;
    unsigned int     priority;
    void            *queue;
    int              mutex_count;
    unsigned int     original_priority;
    unsigned int     priority_inherited;
    unsigned int     state;
    unsigned int     suspend_count;
    unsigned int     wakeup_count;
    unsigned int     wait_info;
    unsigned short   unique_id;
    cyg_threadtimer  timer;
    int              sleep_reason;
    int              wake_reason;
    unsigned int     thread_data[6];
    char            *name;
    void            *list_next;
};
    
#ifdef __cplusplus
}
#endif

Re: mips structure padding

[Eric Christopher]

> r3000 target.  is this is a bug or a feature?  in either case, what
> would be the recommended fix?  thanks,

Can you provide a testcase?

-eric



-- 
I will not use abbrev.

Re: mips structure padding

[mike stump]

> Date: Mon, 28 Jan 2002 18:05:31 -0800
> From: "Todd Malsbary" <toddm@fullplaymedia.com>
> To: <gcc@gcc.gnu.org>

> hi, i have a c structure and a c++ class with the same data members
> and sizeof returns different sizes for each.  i'm wondering exactly
> why that occurs.  i'm building ecos using gcc 3.0.3 targeted for
> mips-r3000-elf.  the purpose of the c structure is to allocate some
> storage for placement new in c++ land.  i can verify that this code
> works on the arm-elf target through various versions of gcc and i'm
> assuming it works for the other mips targets that ecos runs on.  it
> seems to be confined to the r3000 target.  is this is a bug or a
> feature?  in either case, what would be the recommended fix?

Yes, this sounds like a bug report.  Be sure that the text is more
than identical.  Have:

#ifdef __cplusplus
extern "C" {
#endif

struct foo {
       ...
};

#ifdef __cplusplus
}
#endif

in a single header file, include, and that only, and include in your C
and C++ programs, and see if they are laid out the same.  After doing
that, if they differ, then file a bug report, see the documentation
for how to do that.

mips structure padding

[Todd Malsbary]

hi, i have a c structure and a c++ class with the same data members and
sizeof returns different sizes for each.  i'm wondering exactly why that
occurs.  i'm building ecos using gcc 3.0.3 targeted for mips-r3000-elf.
the purpose of the c structure is to allocate some storage for placement
new in c++ land.  i can verify that this code works on the arm-elf
target through various versions of gcc and i'm assuming it works for the
other mips targets that ecos runs on.  it seems to be confined to the
r3000 target.  is this is a bug or a feature?  in either case, what
would be the recommended fix?  thanks,

Todd