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