This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [Gcl-devel] Re: BFD relocations
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)?
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.
Take care,
> --
> Daniel Jacobowitz Carnegie Mellon University
> MontaVista Software Debian GNU/Linux Developer
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah