From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6243 invoked by alias); 16 Jan 2002 16:37:07 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 6207 invoked from network); 16 Jan 2002 16:37:06 -0000 Received: from unknown (HELO atlas.acter.ch) (212.126.160.108) by sources.redhat.com with SMTP; 16 Jan 2002 16:37:06 -0000 Received: (from avbidder@localhost) by atlas.acter.ch (8.11.6/8.11.6/SuSE Linux 0.5) id g0GGb4A02638; Wed, 16 Jan 2002 17:37:04 +0100 X-Authentication-Warning: atlas.acter.ch: avbidder set sender to avbidder@acter.ch using -f Subject: arm/thumb: problems with function pointers From: Adrian von Bidder To: binutils Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution/0.99.2 (Preview Release) Date: Wed, 16 Jan 2002 10:34:00 -0000 Message-Id: <1011199024.1018.5.camel@atlas> Mime-Version: 1.0 X-SW-Source: 2002-01/txt/msg00312.txt.bz2 Heyho! When I do something simple like =3D=3D first file =3D=3D int callee() { return 42; } int main() { return caller(callee); } =3D=3D second file =3D=3D int caller(int (*fn)()) { (fn)(); } =3D=3D end =3D=3D and compile this for arm with -mthumb and -fpic (without -fpic I get a linking error 'bad reloc type 10' so I didn't investigate further), the pointer to callee does not have its lsb set. Since thumb creates a _call_via_rX which uses the bx instruction, callee is called in arm state. I first had callee in a third file so when compiling main callee would be undefined, but having callee together with main does not make a difference. Tools: as always. gcc-3.0.3/binutils-2.11.2 for production, but I made a quick experiment with cvs head (14h old) and afaict it's not been fixed there. I discovered the problem while trying to get a thumbified busybox. any help would be appreciated - I suspect it's similar to the fix [1] Phil Blundell sent me on a similar problem, but it's apparently different enough to need a different fix. (no English teacher reading this? good... ;-)=20 My bet is that what was done to be R_ARM_ABS32 in elf32-arm.h needs to be done to R_ARM_GOT32 relocations, too. But the R_ARM_GOT32 case is more complex than the ABS32 one... Hmmm, I'll probably look at it tomorrow - but I don't know nuffin about bfd, so I'd be glad if somebody else is quicker. =20 greets from Z=FCrich -- vbi [1] 'Re: Linking arm thumb code' from 23 Nov 2001 10:24:39 +0000