HEADSUP: Python 2.7 upgrade

Corinna Vinschen corinna-cygwin@cygwin.com
Thu Jan 24 12:30:00 GMT 2013

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.  The layout of the relocation information is basically an array
> >of relocation blocks, like this:
> >
> >   .reloc section
> >     block1
> >       header
> >	base offset
> >	sizeof following array
> >       array of 2 byte values with:
> >	4 bit relocation type
> >	12 bit offset from base offset
> >     block2
> >       [...]
> >
> >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.
> >
> >What I could reproduce using Marco's ltree.dll example was this:
> >
> >After adding the .gnu_debuglink section, the former NULL block suddenly
> >contained some seemingly random values.  So rebase rightfully assumed
> >that another relocation block is following.  So it happily tried further
> >to relocate the file, until the address falls outside of the allocated
> >memory block, which resulted in the SEGV.
> >
> >To me this indicates a bug in objcopy.
> ok Corinna,
> but on dict_snowball I see a that rebase is
> changing the next section after .reloc
> it is not touching the 00  at the end of
> the .reloc section from 0003 6a60 to 0003 6bf0

rebase does not change the .reloc section.  It uses the information
in the .reloc section to change other file information.  Feel free
to debug rebase yourself.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-apps mailing list