From: Roland (roland.schwarz_at_[hidden])
Date: 2004-08-05 01:40:22
On Wed, 04 Aug 2004 16:25:35 -0500 "Aaron W. LaFramboise" <aaronrabiddog51_at_[hidden]> wrote:
> There are some options for specifying alignment of sections, but note
> this is for linker output, not input. Input sections are aligned
> according to the section symbol, which for .tls$ in my test code for
> both MSVC6 and MSVC7.1 is 2**2, on dword boundaries. If somehow the
> alignment was being set by the compiler/assembler to something higher
> than this, this could account for zeroes. But nothing I have suggests
> that this is happening.
> It's also possible that the compiler (or its assembler machinery) is
> padding variables for some reason, but I don't know why that would be
> happening in this case.
> If you have some specific test case where this happens for you, let me
> know and I'll see exactly what output it gives me.
After having unified your and my code and having compared MSVC& and 7
I came to the following observations so far:
The linker creates a named data segemnet when requested by the object
that has a minimumsize of 260 Bytes. Then it assembles the pointer(s) into this segement.
In the result the sequence:
static _TLSCB pinit1 = mycb1fn;
static _TLSCB pinit2 = mycb2fn;
will end up as initialized memory:
__xl_a : 00 00 00 00
__xl_a+256: 00 00 00 00
adr1+4: 00 00 00 00
.... 00 00 00 00
adr1+256: 00 00 00 00
adr1+264: 00 00 00 00
.... 00 00 00 00
adr1+516: 00 00 00 00
__xl_z: 00 00 00 00
The __xl_a and __xl_z variables that mark the start and end of the
callback area are located on start of segments .CRTXLA and .CRTXLZ
In addition the tlstir.AddressOfCallBacks member is pointing to __xla.
The net result is that the linker is creating an inappropriate PE callback
directory. Consequently I am trying to roeorder the data. (Sidebar: since
I simply move pointers around I think this will not mess with relocation issues.)
Things are very similar with the exception that
tlsdir.AddressOfCallBacks is initialzed to __xla+4 AND the linker has
a minimum segment size of 4 for .CRT$XLx segements. (It does not
show this behaviour for e.g. .CRT$XIx segments.)
The net result is, that it will create a valid PE callback table.
So I think my approach for the fixup is rather conservative. Please note
that it should be possible to run the fixup code even multiple times, without any
negative effect. So this scheme also allows for the use in DLL's
To get more confidence in these observations I grepped into
the LINKER.EXE binary. You can find there explicitely the strings
.CRT$XL and _tls_used. This makes me rather condident that the linker
is the culprit, which gets things wrong.
Even if we have succes in changing the minimum size to 4 bytes,
I still can see no way how we could change AddressOfCallBacks pointing
to the correct entry.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk