From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31459 invoked by alias); 4 Apr 2005 11:59:14 -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 31029 invoked from network); 4 Apr 2005 11:58:58 -0000 Received: from unknown (HELO TopconRD.RU) (62.105.138.7) by sourceware.org with SMTP; 4 Apr 2005 11:58:58 -0000 Received: from osv.topcon.com ([62.105.138.5]) by TopconRD.RU (8.12.3/8.12.3/Debian-6.6) with ESMTP id j34BwfmN002358; Mon, 4 Apr 2005 15:58:41 +0400 To: Nick Clifton Cc: Pieter Arnout , binutils@sources.redhat.com Subject: Re: HELP with linker script!!! References: <13ab0c503312082c7af572c83f523f4f@powerescape.com> <424BE5A7.5060902@redhat.com> <29c1ff0410ff9cc2b88a3ad82d1938aa@powerescape.com> <424D2F42.5070508@redhat.com> <42511F17.5030705@redhat.com> X-attribution: osv From: Sergei Organov Date: Mon, 04 Apr 2005 11:59:00 -0000 In-Reply-To: <42511F17.5030705@redhat.com> Message-ID: <8764z269eb.fsf@osv.topcon.com> User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-04/txt/msg00069.txt.bz2 Nick Clifton writes: [...] > You put the symbols in the linker script, like this: > > .cached_bss : { > __start_of_cacheable_bss = ABSOLUTE (.); > *(.cached_bss) > __end_of_cacheable_bss = ABSOLUTE (.); > } > cachableRAM; > > Then you can reference them from your C code, like this: > > extern int __start_of_cacheable_bss; > extern int __end_of_cacheable_bss; > > memset (& __start_of_cacheable_bss, 0, > & __end_of_cacheable_bss - & __start_of_cacheable_bss); > > Note - read the section entitled "Source Code Reference" in the linker > documentation for an explanation of why these variables are being > accessed via the & operator. Well, please correct me if I'm wrong, but I see two problems here. 1. The variables should better be of type 'char', otherwise pointer arithmetic in the third parameter to memcpy() will bring wrong result. 2. Even then it could be wrong. For example, on PowerPC using SYSV ABI compiler is free to assume the two variables are in the small data section and may generate incorrect assembly and relocation types for the addresses, I'm afraid. Because of this I'd use slightly different approach: extern char __start_of_cacheable_bss[]; extern char __end_of_cacheable_bss[]; memset (__start_of_cacheable_bss, 0, __end_of_cacheable_bss - __start_of_cacheable_bss); The purpose of using arrays of unknown size is to prevent compiler from assuming anything about the location of the variables. -- Sergei.