HEADSUP: Python 2.7 upgrade

marco atzeri marco.atzeri@gmail.com
Sat Jan 26 05:51:00 GMT 2013


On 1/26/2013 1:08 AM, 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.
>

probably the FixImage does no work as rebase is not applied
to the stripped dll, but after the addittion of the
.gnu_debuglink section. The section is small and usually
it is not likely to be covered by the reloc table.
Postgresql has 77 dll's and only 1 hit the problem.

I also noted that using "gcc -shared" instead of "dllwrap" produce
a dict_snowball.dll without the reloc table covering the ".debug_*"

$ objdump -p dict_snowball.dll |grep Virtual
Virtual Address: 00001000 Chunk size 72 (0x48) Number of fixups 32
Virtual Address: 00002000 Chunk size 64 (0x40) Number of fixups 28
[cut]
Virtual Address: 0002d000 Chunk size 312 (0x138) Number of fixups 152
Virtual Address: 0002e000 Chunk size 336 (0x150) Number of fixups 164

$ objdump -h dict_snowball.dll

dict_snowball.dll:     file format pei-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         000162d0  10001000  10001000  00000400  2**4
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .data         00017160  10018000  10018000  00016800  2**5
                   CONTENTS, ALLOC, LOAD, DATA
   2 .edata        00000fde  10030000  10030000  0002da00  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   3 .idata        000002c0  10031000  10031000  0002ea00  2**2
                   CONTENTS, ALLOC, LOAD, DATA
   4 .reloc        00002d40  10032000  10032000  0002ee00  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   5 .debug_aranges 00000440  10035000  10035000  00031c00  2**0
                   CONTENTS, READONLY, DEBUGGING
   6 .debug_pubnames 00000f14  10036000  10036000  00032200  2**0
                   CONTENTS, READONLY, DEBUGGING
   7 .debug_pubtypes 00000ad5  10037000  10037000  00033200  2**0
                   CONTENTS, READONLY, DEBUGGING
   8 .debug_info   00044129  10038000  10038000  00033e00  2**0
                   CONTENTS, READONLY, DEBUGGING
   9 .debug_abbrev 00004873  1007d000  1007d000  00078000  2**0
                   CONTENTS, READONLY, DEBUGGING
  10 .debug_line   00006ee9  10082000  10082000  0007ca00  2**0
                   CONTENTS, READONLY, DEBUGGING
  11 .debug_frame  00001ed8  10089000  10089000  00083a00  2**2
                   CONTENTS, READONLY, DEBUGGING
  12 .debug_str    0000062c  1008b000  1008b000  00085a00  2**0
                   CONTENTS, READONLY, DEBUGGING
  13 .debug_loc    00016d11  1008c000  1008c000  00086200  2**0
                   CONTENTS, READONLY, DEBUGGING
  14 .debug_ranges 0000f388  100a3000  100a3000  0009d000  2**0
                   CONTENTS, READONLY, DEBUGGING

As workaround I will deploy a postgresql release without
debug symbols.

Changing the build system to not use dllwrap will
take some additional time, specially for the testing all
the 77 dll's behaviour.



> 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.
>
> szgyg
>

Regards
Marco




More information about the Cygwin-apps mailing list