From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26159 invoked by alias); 29 Oct 2009 12:46:38 -0000 Received: (qmail 26131 invoked by uid 22791); 29 Oct 2009 12:46:34 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from kuber.nabble.com (HELO kuber.nabble.com) (216.139.236.158) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Oct 2009 12:46:30 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1N3UOa-0005Hm-Aq for gcc@gcc.gnu.org; Thu, 29 Oct 2009 05:46:28 -0700 Message-ID: <26112337.post@talk.nabble.com> Date: Thu, 29 Oct 2009 14:29:00 -0000 From: Bluddy To: gcc@gcc.gnu.org Subject: Possibly gcc/ld bug MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-10/txt/msg00603.txt.bz2 I'm pretty sure I found a bug in psp-gcc (or actually in ld). It may be with the specific psp-gcc/ld bfd or it may be in ld itself. I'm not sure this is the right forum to post this, but hopefully the experts can assist me. I'm working on the PSP (MIPS architecture), doing some unusual linking in Scummvm to get dynamic plugins going. I borrowed the method from the Dreamcast Scummvm code, where it works just fine. Essentially, I use a custom linker file to put all the shorts (.sbss, .sdata) in one area in my main executable, and then I ask ld to keep the relocation entries for the plugin files with the '-q' option, and to take all the symbols from the main executable. Within ScummVM itself I relocate the things in memory. Things were generally working fine in most games. However, looking into one of the games (Kyrandia), I found the following relocations: 0000eb44 00000405 R_MIPS_HI16 000fcf60 .rodata 0000eb48 00000406 R_MIPS_LO16 000fcf60 .rodata 0000eb54 00106206 R_MIPS_LO16 08aecb54 _ZN4Kyra14KyraEngine_L 0000eb58 00223d06 R_MIPS_LO16 08aecb5c _ZN4Kyra14KyraEngine_L Notice that ld is chaining LO16 relocations after HI16's. However, it's doing something completely illegal since the LO16 for 08aecb54 is not preceded by a valid HI16 entry! ld got confused by the two address ranges. The reason I never came across this before is that this is the first time the compiler chose to access things in the shorts section using HI/LO16s instead of GPRELs. I didn't know that was even legal. Since I kept my -G parameter at the default of 8 (i.e. I dropped it), most games never accessed the $gp relative section using HI/LO16s. This is the only game that had arrays of 8 bytes, and I guess the compiler decided it was worth it to just use HI/LO16s to access them. This means also that if I enlarge my -G parameter, I'll get more of these issues. -- View this message in context: http://www.nabble.com/Possibly-gcc-ld-bug-tp26112337p26112337.html Sent from the gcc - Dev mailing list archive at Nabble.com.