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