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