From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-08-04 16:25:35
> Could you send me please a copy of your tlssup.c code? Unfortunately this piece of
> code is missing from the CRT source that is beeing shipped with the compiler.
> mailto: roland.schwarz_at_[hidden]
Give me about 12 hours to produce this in a reasonable form. I have not
yet written it, but have little doubt that this is trivial.
> It seems as if the linker is used to 'assemble' the .CRT$XLx segments.
> Good. From your description it follows, that the linker always keeps
> these segments as small as possible, i.e. it does not append any
> zeroes in between the segments.
> However this is not what I am observing. For me it appears as if each
> segment has a minimum size, which is preset with zeroes. When now
> pointers are filled in, of course there are zeroes between these segment.
> Could it be, that you are using some linker switches that cause the segments
> to be trimmed?
I have not invoked the linker directly, only through CL. I have
verified the behavior I mentioned earlier using a PE dumper and a hex
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.
Aaron W. LaFramboise
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk