Mail Archives: cygwin/2013/01/25/07:34:30
X-Recipient: | archive-cygwin AT delorie DOT com
|
X-SWARE-Spam-Status: | No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_BJ,TW_JC
|
X-Spam-Check-By: | sourceware.org
|
X-Received: | by 10.152.121.212 with SMTP id lm20mr4957850lab.42.1359117222179; Fri, 25 Jan 2013 04:33:42 -0800 (PST)
|
Message-ID: | <51027B9E.3080104@gmail.com>
|
Date: | Fri, 25 Jan 2013 13:33:34 +0100
|
From: | marco atzeri <marco DOT atzeri AT gmail DOT com>
|
User-Agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
|
MIME-Version: | 1.0
|
To: | cygwin AT cygwin DOT com
|
Subject: | Re: Binutils objcopy bug (was Re: rebase segfault)
|
References: | <20130115100745 DOT GC2353 AT calimero DOT vinschen DOT de> <50F5312A DOT 2040503 AT gmail DOT com> <20130115112406 DOT GA13752 AT calimero DOT vinschen DOT de> <50F5D246 DOT 6010902 AT gmail DOT com> <50F653AB DOT 80102 AT gmail DOT com> <20130116123509 DOT GA16991 AT calimero DOT vinschen DOT de> <50F6AD63 DOT 8080106 AT gmail DOT com> <20130124030145 DOT 22fa143f AT YAAKOV04> <20130124092746 DOT GC8311 AT calimero DOT vinschen DOT de> <510103AF DOT 3080305 AT gmail DOT com> <20130124100037 DOT GB24121 AT calimero DOT vinschen DOT de>
|
In-Reply-To: | <20130124100037.GB24121@calimero.vinschen.de>
|
X-IsSubscribed: | yes
|
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm
|
List-Id: | <cygwin.cygwin.com>
|
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com>
|
List-Archive: | <http://sourceware.org/ml/cygwin/>
|
List-Post: | <mailto:cygwin AT cygwin DOT com>
|
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
|
Sender: | cygwin-owner AT cygwin DOT com
|
Mail-Followup-To: | cygwin AT cygwin DOT com
|
Delivered-To: | mailing list cygwin AT cygwin DOT com
|
On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
> I already explained why: The SEGV happens during relocation.
> The file header has been changed already. If you call the
> same rebase, it will try to rebase the file to the same new
> address. If current file base address == requested file base
> address, rebase will return without performing any action.
>
Hi Corinna,
I would like your opinion on this .reloc strange issue of
dict_snowball, as I have the impression I found the root cause.
The relocation table looks the same for the the build, strip and
with debug link dll's
$ objdump -p dict_snowball-strip.dll |grep Virtual |wc -l
130
$ objdump -p dict_snowball-build.dll |grep Virtual |wc -l
130
$ objdump -p dict_snowball-debug.dll |grep Virtual |wc -l
130
but some some sections does not exist anymore after the strip,
so the .reloc table should be smaller after strip.
$ objdump -p dict_snowball-build.dll |grep Virtual
Virtual Address: 00001000 Chunk size 72 (0x48) Number of fixups 32
[cut]
Virtual Address: 0002e000 Chunk size 340 (0x154) Number of fixups 166
[this area points to the .debug_* sections,
starting with .debug_info, up to .debug_loc]
Virtual Address: 0003b000 Chunk size 96 (0x60) Number of fixups 44
Virtual Address: 0003f000 Chunk size 12 (0xc) Number of fixups 2
....
Virtual Address: 00098000 Chunk size 20 (0x14) Number of fixups 6
Virtual Address: 0009a000 Chunk size 12 (0xc) Number of fixups 2
$ objdump -h dict_snowball-build.dll
dict_snowball-build.dll: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00016808 67ec1000 67ec1000 00000400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 00017180 67ed8000 67ed8000 00016e00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .bss 000000f8 67ef0000 67ef0000 00000000 2**5
ALLOC
3 .edata 00000fe0 67ef1000 67ef1000 0002e000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .idata 000003e0 67ef2000 67ef2000 0002f000 2**2
CONTENTS, ALLOC, LOAD, DATA
5 .reloc 0000765c 67ef3000 67ef3000 0002f400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .debug_aranges 00000560 67efb000 67efb000 00036c00 2**0
CONTENTS, READONLY, DEBUGGING
7 .debug_pubnames 00001112 67efc000 67efc000 00037200 2**0
CONTENTS, READONLY, DEBUGGING
8 .debug_pubtypes 00000f49 67efe000 67efe000 00038400 2**0
CONTENTS, READONLY, DEBUGGING
9 .debug_info 00048851 67eff000 67eff000 00039400 2**0
CONTENTS, READONLY, DEBUGGING
10 .debug_abbrev 000050a3 67f48000 67f48000 00081e00 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_line 000078a3 67f4e000 67f4e000 00087000 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_frame 00002114 67f56000 67f56000 0008ea00 2**2
CONTENTS, READONLY, DEBUGGING
13 .debug_str 00000664 67f59000 67f59000 00090c00 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_loc 000170a4 67f5a000 67f5a000 00091400 2**0
CONTENTS, READONLY, DEBUGGING
15 .debug_ranges 0000f3a0 67f72000 67f72000 000a8600 2**0
CONTENTS, READONLY, DEBUGGING
$ objdump -h dict_snowball-strip.dll
dict_snowball-strip.dll: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00016808 67ec1000 67ec1000 00000400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 00017180 67ed8000 67ed8000 00016e00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .bss 000000f8 67ef0000 67ef0000 00000000 2**5
ALLOC
3 .edata 00000fe0 67ef1000 67ef1000 0002e000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .idata 000003e0 67ef2000 67ef2000 0002f000 2**2
CONTENTS, ALLOC, LOAD, DATA
5 .reloc 0000765c 67ef3000 67ef3000 0002f400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
Questions:
- Is it anomalous to have a .reloc portion addressing the
debug_* sections (so the original build file is broken)
- or should strip recognize and remove reloc portion not
anymore relevant ?
rebase is choking on this portion of the .reloc table
>
> Corinna
>
Thansk in advance
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -