HEADSUP: Python 2.7 upgrade

marco atzeri marco.atzeri@gmail.com
Mon Jan 28 10:52:00 GMT 2013

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:
>>> On Jan 24 11:41, marco atzeri wrote:
>>>> On 1/24/2013 10:39 AM, Corinna Vinschen wrote:
>>>>> I debugged this last week, and I don't see how this could be a rebase
>>>>> bug. [...]  To me this indicates a bug in objcopy.
>> Strip copies the whole .reloc section, including entries for removed
>> debug sections. This is documented in rebase/README. Rebase checks
>> for this condition in Relocations::relocate and silently ignores
>> wrong entries. Well, except in Marco's dict_snowball.dll.
>> Btw,
>>>>> 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.
> Corinna

Rebase is not doing wrong. It works on rebasing the stripped file,
as the excess relocation table have no sectors to match.
Unfortunately on the stripped + debug link there is a small
chance that the additional .gnu_debuglink is inside the addresses
of excess relocation table.
Rebase has no way to know that .gnu_debuglink was added later.

In theory both these will help to solve the matter:
-strip should sanitize the .reloc table, but it doesn't care.
-dllwrap should not make binary with relocation of the debug area

It is clear a corner case; my workaround is no debug info when
using dllwrap. Unlikely to happen on general cases


More information about the Cygwin-apps mailing list