Re: HEADSUP: Python 2.7 upgrade

[marco atzeri <marco dot atzeri at gmail dot com>]

On 1/24/2013 10:39 AM, Corinna Vinschen wrote:
> 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:
> > >
> > > ftp://ftp.cygwinports.org/pub/cygwinports/uploads/
> > >
> > > 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
> >
> > http://cygwin.com/ml/cygwin/2013-01/msg00199.html
> >
> > 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
>      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

while is touching the debug section
from 0003 6c00 to 0003 df00

At least it should stop at the end of the .reloc
section anyway


diff -uN dump-debug.txt dump-rebased.txt
[cut]
 0032260 1000 0004 007c 0000 333f 3343 3366 338c
 0032270 3390 33a9 33d1 33d5 33ee 346b 346f 34df
 0032280 34e8 351b 354c 3589 358d 360d 3611 3626
@@ -13928,9 +13930,37 @@
 0036a60 0000 0000 0000 0000 0000 0000 0000 0000
 *
 0036c00 6964 7463 735f 6f6e 6277 6c61 2e6c 6c64
-0036c10 2e6c 6264 0067 0000 86d0 2d33 0000 0000
+0036c10 2e6c 48f5 0067 0000 86d0 2d33 0000 0000
 0036c20 0000 0000 0000 0000 0000 0000 0000 0000
-*
+0036c30 0000 e691 0000 0000 0000 0000 0000 0000
+0036c40 0000 0000 0000 0000 0000 0000 0000 0000
+0036c50 0000 e691 0000 0000 0000 0000 0000 0000
+0036c60 0000 0000 0000 0000 0000 0000 0000 0000
+0036c70 0000 e691 0000 0000 0000 0000 0000 0000
+0036c80 0000 0000 0000 0000 0000 0000 0000 0000
+0036c90 0000 e691 0000 0000 0000 0000 0000 0000
+0036ca0 0000 0000 0000 0000 0000 0000 0000 0000
+0036cb0 0000 e691 0000 0000 0000 0000 0000 0000
+0036cc0 0000 0000 0000 0000 0000 0000 0000 0000
+0036cd0 0000 e691 0000 0000 0000 0000 0000 0000
+0036ce0 0000 0000 0000 0000 0000 0000 0000 0000
+0036cf0 0000 e691 0000 0000 0000 0000 0000 0000
+0036d00 0000 0000 0000 0000 0000 0000 0000 0000
+0036d10 0000 e691 0000 0000 0000 0000 0000 0000
+0036d20 0000 0000 0000 0000 0000 0000 0000 0000
+0036d30 0000 e691 0000 0000 0000 0000 0000 0000
+0036d40 0000 0000 0000 0000 0000 0000 0000 0000
+0036d50 0000 e691 0000 0000 0000 0000 0000 0000
+0036d60 0000 0000 0000 0000 0000 0000 0000 0000
+0036d70 0000 e691 0000 0000 0000 0000 0000 0000
+0036d80 0000 0000 0000 0000 0000 0000 0000 0000
+0036d90 0000 e691 0000 0000 0000 0000 0000 0000
+0036da0 0000 0000 0000 0000 0000 0000 0000 0000
+0036db0 0000 e691 0000 0000 0000 0000 0000 0000
+0036dc0 0000 0000 0000 0000 0000 0000 0000 0000
+0036dd0 0000 e691 0000 0000 0000 0000 0000 0000
+0036de0 0000 0000 0000 0000 0000 0000 0000 0000
+0036df0 0000 e691 0000 0000 0000 0000 0000 0000
 0036e00 0013 0000 672e 756e 645f 6265 6775 696c
-0036e10 6b6e 0000
+0036e10 6b6e 0091
 0036e13





> Corinna