From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18011 invoked by alias); 9 Feb 2015 19:06:41 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 17976 invoked by uid 89); 9 Feb 2015 19:06:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Feb 2015 19:06:39 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id D8DE98E0AA1; Mon, 9 Feb 2015 20:06:36 +0100 (CET) Date: Mon, 09 Feb 2015 19:06:00 -0000 From: Corinna Vinschen To: cygwin-apps@cygwin.com Subject: Re: perl-5.14.4 Message-ID: <20150209190636.GI5633@calimero.vinschen.de> Reply-To: cygwin-apps@cygwin.com Mail-Followup-To: cygwin-apps@cygwin.com References: <87iofh8l54.fsf@Rainer.invalid> <87bnl6n8uw.fsf@Rainer.invalid> <87386gtaub.fsf@Rainer.invalid> <20150209102529.GH28033@calimero.vinschen.de> <87vbjbuhtf.fsf@Rainer.invalid> <20150209184929.GG5633@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="64j1qyTOoGvYcHb1" Content-Disposition: inline In-Reply-To: <20150209184929.GG5633@calimero.vinschen.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-02/txt/msg00111.txt.bz2 --64j1qyTOoGvYcHb1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2088 On Feb 9 19:49, Corinna Vinschen wrote: > On Feb 9 18:15, Achim Gratz wrote: > > Corinna Vinschen writes: > > > I think it's important to keep the information in sync while building > > > the packages. A later rebase will break the connection between debug > > > symbols and runtime symbols as well, obviously. > >=20 > > Obviously? I have no indication that the debug information is damaged > > once it's been stripped off into a separate file. Which may be a hint > > on what rebase might do wrong. >=20 > What I mean is this. If the debug info file does not refer to the > same addresses than the file in memory, then GDB doesn't resolve the > symbols correctly. >=20 > > > Maybe we should think of rebasing the actual binaries as well as their > > > debugging counterparts to keep everything in sync, but that's a bit > > > much effort... > >=20 > > I may not understand what is really going on, but the way I see it, > > rebase does exactly that while the debug information is still part of > > the object file. It seems to do something extra or wrong, since objcopy > > will the not be able to copy out that information. Looking with objdump > > reveals the section is still there ans has contents, but it doesn't get > > associated with the code in the correct manner anymore. >=20 > I'm not an expert on this stuff either, so I can just assume that the > rebasing doesn't catch the debug info and that the debug info then > points into nirvana. I also don't know if there's a way around that. Also, is it possible that we have relocation types in the file which are not handled by rebase? I just had a quick look into the sources and there's a type IMAGE_REL_BASED_ABSOLUTE which is skipped. Or, what if e.g. the expression *patch_adr +=3D difference; in imagehelper/sections.cc is mistreated because of a missing gcc -fwrapv option on the command line? There might be quite a few problems lurking here... Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --64j1qyTOoGvYcHb1 Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU2QU8AAoJEPU2Bp2uRE+g+8gP/A+0+8Gjqn44T/Li2yl9YCHW hfA0nXJH3OI+enUM84/EpglJ9XZPYlx8dYW85p+GgXftJ6hOboUGZykWqu7yh1JE vJF8zVzl16ASvPYR5p1+41ZGZ1mcblRTrVD1ZtFWmAFxi/wjt/Y0sapLjs/nCEr5 kFjLv/vYfwD+3JNh+I6/OIEMUvpl4s2/13S9mmWC/jH6QDGtUjYzNtSyp/Do+Mwb IbSPanLRBB5HvCYjH0QxPRKdtwJruF0ugvW+wzaXQAWYpKsU0yriS7mrhOCimdCk yI6fgU1Nj+h0WglHkaY2TymdxUZZJV+CpteAQDyklz+iXFnM+uhXjNeeV+PkBF1e JMPRgvK3dl33B3Z0Iv0MagpeMKK+0ZN0BWiXL9wmv6lJvxMaJ+Yn6v0gHIW30pdM dCZqkIIa9VXTjyIxL6ElLxJ5Up+2wZETf0JBeIcnFHkGAnW77v2Jz+pnvTXYc/+l D0yUB/HmvADnNSZtY+aQ9fVRKnVX4Mbq5HjpNDT89k6DVOUOPhEplhp3bsYZYNer YjNg1Pyaw6TAZAX81X6l27NNqOB3OsVu3vpm9L0/YSonQ6vU5m20a3Et4A7rmpHR CuiIaHev4Wsqw2yR80cZvV8kMH4OKOFZ0xgvcv50cWrbwXTi8hSi4IcNpIgoj7Mq O1YgPm7YEv3ftAdBG0Nq =n+WG -----END PGP SIGNATURE----- --64j1qyTOoGvYcHb1--