From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30213 invoked by alias); 14 Jun 2013 13:37:20 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 30204 invoked by uid 89); 14 Jun 2013 13:37:19 -0000 X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,SPF_NEUTRAL autolearn=no version=3.3.1 Received: from gateway09.websitewelcome.com (HELO gateway09.websitewelcome.com) (64.5.52.12) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 14 Jun 2013 13:37:18 +0000 Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 20A787292FDE5; Fri, 14 Jun 2013 08:36:41 -0500 (CDT) Received: from ham02.websitewelcome.com (unknown [173.192.111.51]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 07E747292FD87 for ; Fri, 14 Jun 2013 08:36:41 -0500 (CDT) Received: by ham02.websitewelcome.com (Postfix, from userid 666) id EAA3E25FEC76F; Fri, 14 Jun 2013 08:37:16 -0500 (CDT) X-Spam-Flag2999: NO X-Spam-Level2999: X-Spam-Status2999: "No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received: from montecarlo.websitewelcome.com (montecarlo.websitewelcome.com [174.120.9.66]) by ham02.websitewelcome.com (Postfix) with ESMTP id 5BD2325FEBACB for ; Fri, 14 Jun 2013 08:37:14 -0500 (CDT) Received: from [213.115.176.230] (port=47783 helo=[192.168.0.232]) by montecarlo.websitewelcome.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UnUBl-0002lX-Vr; Fri, 14 Jun 2013 08:37:14 -0500 Message-ID: <51BB1C87.3050204@siva.com.mk> Date: Fri, 14 Jun 2013 13:37:00 -0000 From: Ilija Kocho User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kai Ruottu CC: gcc-help@gcc.gnu.org Subject: Re: gcc Cortex M4 bug ? References: <51B9F7EF.5010007@wippies.com> In-Reply-To: <51B9F7EF.5010007@wippies.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BWhitelist: no X-Source-Sender: ([192.168.0.232]) [213.115.176.230]:47783 X-Source-Auth: ilijak+siva.mk X-Email-Count: 1 X-Source-Cap: c2l2YW1rO2JpYmltYW47bW9udGVjYXJsby53ZWJzaXRld2VsY29tZS5jb20= X-SW-Source: 2013-06/txt/msg00107.txt.bz2 On 13.06.2013 18:48, Kai Ruottu wrote: > 13.6.2013 12:25, matti h kirjoitti: >> Hi, >> Im trying to implement a dynamic linker for M4 mcu's. >> But the generated code from gcc seems incorrect to me: im compiling >> using >> arm-none-eabi-gcc: -mcpu=cortex-m4 -mthumb -O2 -ggdb >> -Wstrict-prototypes >> -Wunused-parameter -lmylib main.c -o test > > For me this all looks insane :( > > I would expect the 'arm-eabi' target being purely static and not > knowing anything about > shared libraries and dynamic linking, something equivalent to the > 'arm-elf' target but with > somehow different object format. Meanwhile targets like 'arm-linux*', > 'arm-*bsd' etc. will > support dynamic linking. If we look at the Wikipedia page : > > http://en.wikipedia.org/wiki/Application_binary_interface > > there is told : > > "The main differences of an EABI with respect to an ABI for general > purpose operating > systems are that privileged instructions are allowed in application > code, dynamic linking > is not required (sometimes it is completely disallowed), and a more > compact stack frame > organization is used to save memory." /Not required/ doesn't mean /not desirable/ (though /disallowed/ implies). It also doesn't mean that EABI hinders dynamic object loading. An example is eCos (http://ecos.sourceware.org) that uses ARM EABI and yet supports dynamic object loading. Ilija