From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22498 invoked by alias); 17 Jun 2006 13:14:29 -0000 Received: (qmail 22482 invoked by uid 22791); 17 Jun 2006 13:14:29 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 17 Jun 2006 13:14:27 +0000 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 67EB41CC39; Sat, 17 Jun 2006 15:14:20 +0200 (CEST) From: Andreas Schwab To: Mattias Bertilsson Cc: gdb@sourceware.org, binutils@sourceware.org Subject: Re: Problem with gdb relocation of debug info References: <4493F8EC.8040106@enea.com> Date: Sat, 17 Jun 2006 15:35:00 -0000 In-Reply-To: <4493F8EC.8040106@enea.com> (Mattias Bertilsson's message of "Sat, 17 Jun 2006 14:43:24 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00276.txt.bz2 Mattias Bertilsson writes: > It seems the reason is the relocation of the .debug_info section that is > initiated in symfile_relocate_debug_section() in gdb/symfile.c and the > definition of the "howto" structs in bfd/elf32-mips.c and > bfd/elfarm-[n|o]abi.c. > > For powerpc, src_mask is 0, so for relocations such as R_PPC_ADDR32 the > DOIT() macro in bfd_perform_relocation() in bfd/relocate.c will correctly > replace what was at the patch location with the new value. > > For arm and mips, however, src_mask often equals dest_mask, even for > relocations that should patch in a constant value (such as > R_ARM_ABS32). The result for us, where the value at the patch location is > not 0, is that we, instead of patching in a constant, end up with the sum > of whatever was at the patch location and the new value. For targets that use REL (intead of RELA) relocation the addend is stored in the source field instead of the relocation entry, so ignoring the previous section contents would be wrong. Since both ARM and MIPS use REL relocations BFD is doing the right thing here. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."