public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Sergei Organov <osv@topconrd.ru>
To: Nick Clifton <nickc@redhat.com>
Cc: Pieter Arnout <pieter@powerescape.com>, binutils@sources.redhat.com
Subject: Re: HELP with linker script!!!
Date: Mon, 04 Apr 2005 11:59:00 -0000	[thread overview]
Message-ID: <8764z269eb.fsf@osv.topcon.com> (raw)
In-Reply-To: <42511F17.5030705@redhat.com>

Nick Clifton <nickc@redhat.com> 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.

  parent reply	other threads:[~2005-04-04 11:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-31 14:42 Pieter Arnout
2005-03-31 15:50 ` Nick Clifton
     [not found]   ` <29c1ff0410ff9cc2b88a3ad82d1938aa@powerescape.com>
2005-04-01 11:27     ` Nick Clifton
2005-04-01 12:53       ` Vincent Rubiolo
2005-04-01 14:05         ` Nick Clifton
2005-04-01 14:13           ` Dave Korn
2005-04-01 14:34             ` Andreas Schwab
2005-04-01 16:53       ` Pieter Arnout
2005-04-04  9:39         ` Vincent Rubiolo
2005-04-04 11:06         ` Nick Clifton
2005-04-04 11:11           ` Dave Korn
2005-04-04 11:59           ` Sergei Organov [this message]
2005-04-04 13:39             ` Nick Clifton
2005-03-31 15:08 Zagorodnev, Grigory

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8764z269eb.fsf@osv.topcon.com \
    --to=osv@topconrd.ru \
    --cc=binutils@sources.redhat.com \
    --cc=nickc@redhat.com \
    --cc=pieter@powerescape.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).