This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: HEADSUP: Python 2.7 upgrade
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
Regards
Marco