HEADSUP: Python 2.7 upgrade
Mon Jan 28 13:25:00 GMT 2013
I didn't see the discussion on the other list. Oh, well.
On 1/28/2013 11:35 AM, Corinna Vinschen wrote:
> On Jan 26 01:08, szgyg wrote:
>> On 1/24/2013 1:29 PM, Corinna Vinschen wrote:
>>>>> The size of the .reloc section in the file header does not indicate how
>>>>> long the relocation information in the section actually is. Usually the
>>>>> section is larger than the actual relocation info. The end of the
>>>>> relocation info is indicated by a block header with a base offset of 0
>>>>> and a sizeof of 0, let's call it the NULL block.
>> VirtualSize (offset 8 in section header) should be exact. There are
>> no terminator zero block, but can be zero section padding.
>> VirtualSize + padding = SizeOfRawData.
> Are you implying that rebase (or better: the included imagehelper lib)
> is doing the right thing, or not? The size of the reloc section is
> taken from SizeOfRawData. Relocations::check checks if the data is
> within a valid section. I just don't see what it's doing wrong there.
This problem is unrelated to the segfault.
Relocations::relocate does a strange thing that works by accident. See
&relocp->SizeOfBlock < (PDWORD) ((char *)relocs + size)
&& relocp->SizeOfBlock != 0;
After the last relocation block, the first half of the condition is
false if we have 0 or 1 DWORD of padding, and the second half is false
if the second DWORD of padding is 0. As paddings should be all zeros,
this condition always terminates the loop, but I wouldn't write it in
this way. A better form is something like
relocp < relocs + virtual_size
Relocations::fix is broken, but hopefully it doesn't run on dlls not
created by dllwrap. It should set VirtualSize and zero out the remaining
part of .reloc. Right now it leaves a .reloc with an invalid, 0-size
block and additional garbage.
More information about the Cygwin-apps