This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: HEADSUP: Python 2.7 upgrade

On Jan 24 06:49, marco atzeri wrote:
> On 1/24/2013 1:56 AM, Yaakov (Cygwin/X) wrote:
> >Jason Tishler announced last month[1] that he intends to upgrade Python
> >to 2.7 on 01 February, which is quickly approaching.
> >
> >If anybody needs them, my Python-dependent distro packages have been rebuilt and are available in a staging area here:
> >
> >
> >
> >In order to assure a prompt and smooth transition to Python 2.7, the
> >following packages will need a rebuild/update:
> >
> >Marco Atzeri: postgresql
> postgresql upgrade is blocked by a rebase/objcopy issue
> also patching cygport to use
>  "--long-section-names enable"  together with "--add-gnu-debuglink"
> one of the dll "dict_snowball-dll" causes rebase to segfault
> I am not sure if it is objcopy creating a bugged debuglink dll,
> or it is rebase incorrectly choking on it.

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
	base offset
	sizeof following array
      array of 2 byte values with:
	4 bit relocation type
	12 bit offset from base offset

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.


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]