From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25849 invoked by alias); 9 Aug 2010 12:09:26 -0000 Received: (qmail 25706 invoked by uid 22791); 9 Aug 2010 12:09:22 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_00,TW_BJ,TW_JC X-Spam-Check-By: sourceware.org Received: from saarni.dnainternet.net (HELO saarni.dnainternet.net) (83.102.40.136) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Aug 2010 12:09:17 +0000 Received: from localhost (localhost [127.0.0.1]) by saarni.dnainternet.net (Postfix) with ESMTP id 89F9BE658A for ; Mon, 9 Aug 2010 15:09:14 +0300 (EEST) X-Spam-Score: -1.36 Received: from saarni.dnainternet.net ([83.102.40.136]) by localhost (saarni.dnainternet.net [127.0.0.1]) (amavisd-new, port 10041) with ESMTP id komLJgjXD9kN for ; Mon, 9 Aug 2010 15:09:14 +0300 (EEST) Received: from kirsikkapuu.dnainternet.net (kirsikkapuu.dnainternet.net [83.102.40.214]) by saarni.dnainternet.net (Postfix) with ESMTP id 5FABFE6586 for ; Mon, 9 Aug 2010 15:09:14 +0300 (EEST) Received: from [127.0.0.1] (82-128-244-167-Rajakyla-TR1.suomi.net [82.128.244.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kirsikkapuu.dnainternet.net (Postfix) with ESMTPS id 4A5582BAD9 for ; Mon, 9 Aug 2010 15:09:13 +0300 (EEST) Message-ID: <4C5FEFEB.4070004@finwe.fi> Date: Mon, 09 Aug 2010 12:39:00 -0000 From: =?ISO-8859-1?Q?Heikki_Ker=E4nen?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: binutils@sourceware.org Subject: Linking against armlink produced ELF for armv6-m (thumb only) CPU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-08/txt/msg00112.txt.bz2 Hi, I have found no good solution to this problem. Can anyone help? We have a ROM image produced by RVCT toolchain: armlink produces .axf -file which is in ELF-format. Now we would like to create an executable to the RAM by using the GNU-toolchain. Those RAM-executables should of course link against functions in ROM. If I have understood everything right the correct way to do this is to link against this armlink produced ELF-file by using option "--just-symbols=romimagefile.elf". Everything works when I link against a ROM image ELF-file produced by the ld -linker, but when I link against armlink -produced ELF-file the following happens: Build finishes, but in the ld -linker prints out a following error message: "Conflicting CPU architectures 11/0". Also the veneers generated by the ld -linker seem to contain ARM-instructions although we have a thumb-only CPU architecture (armv6-m). Binutils ld -linker does not seem to have any command line options to select or force certain arm-architecture like armlink does. If I understood right, it is doing the guessing based on the .ARM.attributes -sections in the input files. I have examined differences in the ld and armlink produced ELF-files and it seems that armlink does not put .ARM.attributes -section into the ELF-file like ld does. When the .ARM.attributes -section is missing the ld -linker assumes the architecture of that file is "TAG_CPU_ARCH_PRE_V4" (which equals 0 in arm.h), and generates veneers according to that. And of course our thumb-only CPU raises an exception when it meets an arm instruction in the veneer. Because I have found no way to enable armlink to generate .ARM.attributes -section to the ELF-file and ld does not work in the desired way without this information I'am in a dead end. To work around the problem I have tried to copy an .ARM.attributes -section from ld generated ELF to armlink generated ELF by using binutils objcopy with option --add-section, but I have found no way to set the section type to ARM_ATTRIBUTES, which seems to be required by the ld -linker. I have also tried to refer to the ROM symbols by introducing them in a linker script -file, but the problem is that there is no way to tell ld that these symbols refer to thumb-code and again the linker is generating veneers containing arm instructions. The binutils I'am using is a self compiled CVS snapshot: "GNU ld (GNU Binutils) 2.20.51.20100802" The only way I have managed to create a working executable is to modify the ld -linkers 'using_thumb_only' -function in elf32-arm.c to return always true, which of course is not an sustainable solution in the long term. Is there something I have not found by myself I could try or is this problem right now a compatibility problem with no solution? What would be the best solution in the long term? Heikki K.