This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Gcl-devel] Re: BFD relocations


On Wed, Jun 05, 2002 at 08:21:24PM -0400, Camm Maguire wrote:
> Thanks as always.  Forgot two more:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > On Wed, Jun 05, 2002 at 07:03:51PM -0400, Camm Maguire wrote:
> > > Greetings!  Many thanks again!
> > > 
> > > This works without problem!  Hooray!
> > > 
> > > 1) Is it possible to know for sure that a smaller range could be
> > >    flushed safely?
> > 
> > I believe glibc has an "aux" mechanism to convey this.  I don't know
> > how it works, though.  Geoff?
> > 
> > > 2) Any other machines supported by binutils which require similar
> > >    flushing?  Assembly instructions?
> > 
> > Almost every machine has some requirements here; if x86 does not expose
> > them than that is probably a remnant of its CISC beginnings.  You will
> > need to look through glibc's loader code, I expect.
> > 
> > > 3) Separately, do you know what the alignment requirements are for
> > >    sparc32 user code on a sparc64 system?  I'm getting a SIGBUS on
> > >    Debian sparc, but the relevant addresses seem to be aligned on 8
> > >    byte boundaries, which I thought should be plenty.
> > 
> > Probably again a cache issue.
> > 
> 
> 4) Does cache corruption always result in a signal delivery?  -- My
>    guess, no.  If so, is the only other definitive symptom of missing
>    cache flushing unexplained memory corruption, (which itself of
>    course is not definitive)?

Exactly.  There are no definitive symptoms of missing cache flushes
(although each architecture will tend to have a "usual" behavior).

> 5) On RISC machines, when is cache flushing generally necessary, apart
>    from the already identified case of reading in executable code and
>    jumping to it from within the program?  Why does the write to
>    memory on program load not dirty the cache, and instruct the cpu to
>    reread from main memory?   It would seem that any case of passing
>    function pointers around might require a cache flush.

On many RISC systems, and probably many non-RISC, the data cache is not
synchronized to the instruction cache.  The icache will not fetch
blocks from the data cache, only direct from main memory.  So if it's
in-cache and dirty...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]