From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11489 invoked by alias); 25 Jan 2013 13:20:09 -0000 Received: (qmail 11378 invoked by uid 22791); 25 Jan 2013 13:20:07 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_BJ,TW_JC X-Spam-Check-By: sourceware.org Received: from mail-ia0-f174.google.com (HELO mail-ia0-f174.google.com) (209.85.210.174) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Jan 2013 13:19:33 +0000 Received: by mail-ia0-f174.google.com with SMTP id o25so585448iad.5 for ; Fri, 25 Jan 2013 05:19:33 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.194.167 with SMTP id hx7mr3994388igc.99.1359119973024; Fri, 25 Jan 2013 05:19:33 -0800 (PST) Received: by 10.64.34.172 with HTTP; Fri, 25 Jan 2013 05:19:32 -0800 (PST) In-Reply-To: <51027B9E.3080104@gmail.com> References: <20130115100745.GC2353@calimero.vinschen.de> <50F5312A.2040503@gmail.com> <20130115112406.GA13752@calimero.vinschen.de> <50F5D246.6010902@gmail.com> <50F653AB.80102@gmail.com> <20130116123509.GA16991@calimero.vinschen.de> <50F6AD63.8080106@gmail.com> <20130124030145.22fa143f@YAAKOV04> <20130124092746.GC8311@calimero.vinschen.de> <510103AF.3080305@gmail.com> <20130124100037.GB24121@calimero.vinschen.de> <51027B9E.3080104@gmail.com> Date: Fri, 25 Jan 2013 13:20:00 -0000 Message-ID: Subject: Re: Binutils objcopy bug (was Re: rebase segfault) From: Kai Tietz To: cygwin@cygwin.com Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2013-01/txt/msg00361.txt.bz2 2013/1/25 marco atzeri : > 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 Well, here are my 2-cents about that issue. In general it is a flaw to have an base-relocation in debug-section, as this means such a section can't be moved into a separate debug-file anymore, due that has no relocation-information. Nevertheless it would be good, if objcopy gets adjusted to eliminated base-relocations of stripped sections. Kai -- 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