Problems with "default" alignment beeing different

[Hendrik Schober]

Hi,

we just run into the problem, that "default" alignment
in the project properies dialog seem to be different.
We have a project that's a DLL, which is linked with
a couple of LIBs. All are with the same solution. All
had "Default" set in the "Struct Member Alignment"
entry.
After some assembler debugging we found out that a
struct member that is a member function pointer in
one of the LIBs was expected at a different position
than in the DLL.
Setting the alignment to /Zp4 in all projects made
the problem disappear.

I don't understand that.
What's the "Default" setting defaulting to? And why
is that different in projects of the same solution?

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers org

"And why should I know better by now/When I'm old enough not to?"
Beth Orton

[Tanveer Gani [MSFT]]

--------------------

From: "Hendrik Schober" <Sp******@gmx.d e>
Subject: Problems with "default" alignment beeing different
Date: Wed, 3 Sep 2003 12:35:56 +0200
Lines: 29
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <Os************ **@TK2MSFTNGP10 .phx.gbl>
Newsgroups: microsoft.publi c.dotnet.langua ges.vc
NNTP-Posting-Host: 212.99.150.86
Path: cpmsftngxa06.ph x.gbl!TK2MSFTNG P08.phx.gbl!TK2 MSFTNGP10.phx.g bl
Xref: cpmsftngxa06.ph x.gbl microsoft.publi c.dotnet.langua ges.vc:27852
X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.vc

Hi,

we just run into the problem, that "default" alignment
in the project properies dialog seem to be different.
We have a project that's a DLL, which is linked with
a couple of LIBs. All are with the same solution. All
had "Default" set in the "Struct Member Alignment"
entry.
After some assembler debugging we found out that a
struct member that is a member function pointer in
one of the LIBs was expected at a different position
than in the DLL.
Setting the alignment to /Zp4 in all projects made
the problem disappear.

I don't understand that.
What's the "Default" setting defaulting to? And why
is that different in projects of the same solution?

Schobi

--
Sp******@gmx.d e is never read
I'm Schobi at suespammers org

"And why should I know better by now/When I'm old enough not to?"
Beth Orton

Hi Schobi,

You can inspect the log file to see if any other alignment was being
specified. Once a build is done, a link is provided to an HTML version of
the log file in the Output window. Note that the value of the default
alignment is different for different platforms. On x86, it's /Zp4; on IA64
it's /Zp8, etc.

However, the fact that a pointer-to-member was involved causes me to think
of one other case that can cause different packing of structures containing
pointers to members. Consider this:

// File 1.cpp:

struct C; // no definition provided <------------- NOTE THIS

typedef void (C::*PTM)();

struct X {
PTM ptm1;
PTM ptm2;
};

// File 2.cpp

struct C { /*...*/ }; /* definition provided */

typedef void (C::*PTM)();

struct X {
PTM ptm1;
PTM ptm2;
};
You'll find that the size of struct X in the two translation units is
different because in 1.cpp, since the inheritance characteristics
(multiple, virtual, none) of struct C are unknown, VC presumes the most
general kind of pointer to member and allocates more than 4 bytes to it.
This can cause the offsets of ptm2 to be different in the two translation
units. It's worth checking that in all translation units were a pointer to
member of class C is defined, the definition of class C is available. If C
is an instantiatable class (doesn't contain any pure virtuals or private
default constructors), a simple definition of a global (static) variable
should do the job.

--
Tanveer Gani, Microsoft Visual C++ Team
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

[Hendrik Schober]

"Tanveer Gani [MSFT]" <tg***@online.m icrosoft.com> wrote:

[...]
Hi Schobi,

You can inspect the log file to see if any other alignment was being
specified. Once a build is done, a link is provided to an HTML version of
the log file in the Output window. Note that the value of the default
alignment is different for different platforms. On x86, it's /Zp4; on IA64
it's /Zp8, etc.
I know. There wasn't any difference between the
LIB and DLL project that seemed important.
However, putting the LIB's sources into the DLL
cured the problem.
However, the fact that a pointer-to-member was involved causes me to think
of one other case that can cause different packing of structures containing
pointers to members. Consider this:

[...]
That's interesting. I didn't know that.
However, since simply putting the sources into
the same project cured the problem, it seems
unlikely that this was the cause.

I'm afraid the guy who run into this feels he
wasted too much time on this issue and won't
put anymore into this now that he found some
workaround. I hope that won't bite us in the
end, but I can't find any time either.

Thanks for looking into this.
Tanveer Gani, Microsoft Visual C++ Team

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers org

"And why should I know better by now/When I'm old enough not to?"
Beth Orton

[Hendrik Schober]

"Hendrik Schober" <Sp******@gmx.d e> wrote:

Hi,

we just run into the problem, that "default" alignment
in the project properies dialog seem to be different.
We have a project that's a DLL, which is linked with
a couple of LIBs. All are with the same solution. All
had "Default" set in the "Struct Member Alignment"
entry.
After some assembler debugging we found out that a
struct member that is a member function pointer in
one of the LIBs was expected at a different position
than in the DLL.
Setting the alignment to /Zp4 in all projects made
the problem disappear.
[...]

Unfortunately, it didn't make it disappear,
it just changed the problem, so that it arose
somewhere else.
We have been further investigating this. So
here's an update.

We compile a bunch of code into a LIB file and
link this into our executable. (The code isn't
ours.)
It seems as if pointers to member functions are
aligned differently in the LIB than in the EXE,
even though all compiler settings are the same.
(We checked this several times.)

Assuming I want to use pointers to a struct's
members within a table like this

const TTestStruct c::sm_TestEntri es[] = {
{ 1, 2, 3, &c::f1, &var},
{ 4, 5, 6, &c::f1, &var},
{ 0, 0, 0, 0, 0}
};

using default alignment I end up with this
memory layout (all in 4byte words):

0001 0002 0003 0000 &f1 0000 0000 0000 &var
0004 0005 0006 0000 &f1 0000 0000 0000 &var
0000 0000 0000 0000 0000 0000 0000 0000 0000

Using 4byte alignment (/Zp4) I get this:

0001 0002 0003 &f1 0000 0000 0000 &var
0004 0005 0006 &f1 0000 0000 0000 &var
0000 0000 0000 0000 0000 0000 0000 0000

So far, so good. However, in the LIB I get
this:

0001 0002 0003 &f1 &var
0004 0005 0006 &f1 &var
0000 0000 0000 0000 0000

no matter what the alignment is set to.
I know that smells as if the alignment is set
explicitely somewhere within the code. However,
there's a few things against this:
1. Despite intensive search by three people
(including me), we didn't find any.
2. It used to work with VC6.
3. A '#pragma pack(show)' at the appropriate
places showed identical values for LIB and
EXE.
While I would argue about #1, probably even #2,
#3 seems to indicate that there isn't any packing
manipulation done.
We haven't been able to come up with a repro case
and the code in question is rather big. So we
merely are still blindly stumbling around,
searching for something to start with.
Any ideas out there about that?

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers org

"And why should I know better by now/When I'm old enough not to?"
Beth Orton

[Ronald Laeremans [MSFT]]

Try and compile everything explicitly with /vmg /vmv (or /vmg /vmm if you
use MI, but not virtual inheritance). Look at the help for both compiler
options for more background.

Ronald Laeremans
Visual C++ team

"Hendrik Schober" <Sp******@gmx.d e> wrote in message
news:ej******** ******@TK2MSFTN GP09.phx.gbl...

"Hendrik Schober" <Sp******@gmx.d e> wrote:

Hi,

we just run into the problem, that "default" alignment
in the project properies dialog seem to be different.
We have a project that's a DLL, which is linked with
a couple of LIBs. All are with the same solution. All
had "Default" set in the "Struct Member Alignment"
entry.
After some assembler debugging we found out that a
struct member that is a member function pointer in
one of the LIBs was expected at a different position
than in the DLL.
Setting the alignment to /Zp4 in all projects made
the problem disappear.
[...]

Unfortunately, it didn't make it disappear,
it just changed the problem, so that it arose
somewhere else.
We have been further investigating this. So
here's an update.

We compile a bunch of code into a LIB file and
link this into our executable. (The code isn't
ours.)
It seems as if pointers to member functions are
aligned differently in the LIB than in the EXE,
even though all compiler settings are the same.
(We checked this several times.)

Assuming I want to use pointers to a struct's
members within a table like this

const TTestStruct c::sm_TestEntri es[] = {
{ 1, 2, 3, &c::f1, &var},
{ 4, 5, 6, &c::f1, &var},
{ 0, 0, 0, 0, 0}
};

using default alignment I end up with this
memory layout (all in 4byte words):

0001 0002 0003 0000 &f1 0000 0000 0000 &var
0004 0005 0006 0000 &f1 0000 0000 0000 &var
0000 0000 0000 0000 0000 0000 0000 0000 0000

Using 4byte alignment (/Zp4) I get this:

0001 0002 0003 &f1 0000 0000 0000 &var
0004 0005 0006 &f1 0000 0000 0000 &var
0000 0000 0000 0000 0000 0000 0000 0000

So far, so good. However, in the LIB I get
this:

0001 0002 0003 &f1 &var
0004 0005 0006 &f1 &var
0000 0000 0000 0000 0000

no matter what the alignment is set to.
I know that smells as if the alignment is set
explicitely somewhere within the code. However,
there's a few things against this:
1. Despite intensive search by three people
(including me), we didn't find any.
2. It used to work with VC6.
3. A '#pragma pack(show)' at the appropriate
places showed identical values for LIB and
EXE.
While I would argue about #1, probably even #2,
#3 seems to indicate that there isn't any packing
manipulation done.
We haven't been able to come up with a repro case
and the code in question is rather big. So we
merely are still blindly stumbling around,
searching for something to start with.
Any ideas out there about that?

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers org

"And why should I know better by now/When I'm old enough not to?"
Beth Orton

[Hendrik Schober]

"Ronald Laeremans [MSFT]" <ro*****@online .microsoft.com> wrote:

Try and compile everything explicitly with /vmg /vmv (or /vmg /vmm if you
use MI, but not virtual inheritance). Look at the help for both compiler
options for more background.
Thanks for looking at this, Ronald.

In the test project we have to play with this
(it doesn't reproduce the problenm, though), we
see how this affects the member pointer layout.
It doesn't seem to solve the problem in the real
project, though. (AFAIK there isn't any pointer
into a forward declared class' member involved.)

However, this seems to hint at the problem. As
the problem was explained to me, it seems that
there is a class hierarchy in the LIB that doesn't
have MI. There's an array defined, which contains
pointers to members of classes from that hierarchy.
In the executable, there's further inheritance
from those classes, this time involving MI.
Right now we try to remove that MI (it seems it
isn't really necessary) to see if that helps.
Ronald Laeremans
Visual C++ team
[...]

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers org

"And why should I know better by now/When I'm old enough not to?"
Beth Orton