On 10-Sep-2007, at 15:31 , mkalkal wrote:
I found problem in structure packing in mingw32ce.
Here is output from wa_.c file compiled by mingw32ce :
sizeof(t1) = 12
(t1)offset f2 =4
(t1)offset f3 =8
(t1)offset f4 =9
sizeof(t2) = 16
(t2)offset f2 =4
(t2)offset f3 =12
(t2)offset f4 =13
Output (Visual C) :
sizeof(t1) = 12
(t1)offset f2 =4
(t1)offset f3 =8
(t1)offset f4 =9
sizeof(t2) = 24
(t2)offset f2 =8
(t2)offset f3 =16
(t2)offset f4 =17
When structure doesn't contain long long field everything is OK,
but when structure contain such field
in visual c integer types like (unsigned short) occupies 8 bytes
(in mingw32ce 4 bytes).
Is this a bug ?,or is there a compiler (switch / directive ) to walk
around this problem?
Funny!
I just came across this problem last week, while compiling the ffmpeg
libraries with mingw32ce for use in a Visual Studio 2005 project.
For some reason my post was held up, and I didn't repost yet because
I found a workaround in the mean time and I hadn't had time to
rephrase the message. (I've copied my original message below).
The workaround is to use a typedef for the long long, and use
__attribute__((aligned(8))) when declaring it. In my case the problem
was offset_t, so I changed the typedef to
typedef int64_t offset_t
#if defined(__GNUC__)
__attribute__((aligned(8)))
#endif
;
Still, a compiler option would be better. There are a couple of gcc
options (for other platforms) that mean things like "strictly adhere
to the ABI for XXXX", something like that would be good. That is,
assuming there's a reason for the 4-byte alignment in stead of 8-byte
alignment.
Here's my original message, as google-bait:
From: Jack Jansen <[EMAIL PROTECTED]>
Date: September 6, 2007 11:31:41 GMT+02:00
To: [EMAIL PROTECTED]
Subject: Problem with struct-alignment when building ffmpeg for use
with VC++
I've run into a problem with mingw32ce that I could use some help
with. That is, aside from all the help already provided in the
archives of this mailing list, thanks folks!
My current problem is that there are slight differences in the
struct alignment rules between gcc and VC++8 for arm.
I'm building ffmpeg as a shared library with mingw32ce, following a
pattern similar to what I found in the archives here. Then I use
the Microsoft "lib" tool to turn the .def files into .lib files and
use those in my Visual Studio 2005 project, and copy the .dll files
to the device (actually the emulator, at the moment, because I'm
still having a DLL problem with the actual device, but that's not
the issue here). I'm building for armv4 right now because that's
all the emulator understands (which means I have to hand-compile
dsputil_arm_s.S because it uses armv5 instructions, but that's also
beside the point).
After a lot of debugging and tweaking things everything is starting
to work, but the layout of the AVFormatContext struct (from
avformat.h) is different in gcc and vc++. It turns out the culprit
is the ByteIOContext structure (from avio.h): on the mingw32ce side
this structure is 76 bytes long, on the vc++ side it's 80 bytes. I
think the problem are the offset_t members in that structure, these
are int64_t's.
Apparently this cause vc++ to extend the structure size to a
multiple of 8 bytes, whereas gcc does not do this.
My question is twofold, really:
1. I think Microsoft is right here (for once:-): shouldn't
structures be padded such that the alignment of the biggest member
isn't violated if you create an array of these structures? Or is
there another rule in place here that I'm not aware of?
2. Is there any compiler option or pragma or somesuch that I could
use to change this, preferably on the mingw32ce side?
Hmm, actually I have a third question: I've seen a couple of posts
by people who also built ffmpeg with mingw32ce for use with vc++,
I'm surprised that they haven't run into this problem.
AVFormatContext is truly messed up for me...
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
