From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32445 invoked by alias); 4 Apr 2005 13:39:10 -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 32011 invoked from network); 4 Apr 2005 13:38:44 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 4 Apr 2005 13:38:44 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j34DcixS027403 for ; Mon, 4 Apr 2005 09:38:44 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j34DcgO20021; Mon, 4 Apr 2005 09:38:43 -0400 Received: from [172.31.0.98] (vpnuser4.surrey.redhat.com [172.16.9.4]) by pobox.surrey.redhat.com (8.12.8/8.12.8) with ESMTP id j34DcfpH011206; Mon, 4 Apr 2005 14:38:42 +0100 Message-ID: <425142CB.80107@redhat.com> Date: Mon, 04 Apr 2005 13:39:00 -0000 From: Nick Clifton User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: Sergei Organov 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> <8764z269eb.fsf@osv.topcon.com> In-Reply-To: <8764z269eb.fsf@osv.topcon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-04/txt/msg00074.txt.bz2 Hi Sergei, > 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. Good points - thanks for making them. Cheers Nick