From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22550 invoked by alias); 6 Jun 2002 00:21:31 -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 22541 invoked from network); 6 Jun 2002 00:21:29 -0000 Received: from unknown (HELO intech19.enhanced.com) (66.134.96.17) by sources.redhat.com with SMTP; 6 Jun 2002 00:21:29 -0000 Received: from camm by intech19.enhanced.com with local (Exim 3.12 #1 (Debian)) id 17Fl1o-0003aj-00; Wed, 05 Jun 2002 20:21:24 -0400 To: Daniel Jacobowitz Cc: binutils@sources.redhat.com, gcl-devel@gnu.org Subject: Re: [Gcl-devel] Re: BFD relocations References: <20020603050518.GA18965@branoic.them.org> <54vg90uibg.fsf@intech19.enhanced.com> <20020603222917.GA945@branoic.them.org> <54vg8ybuey.fsf@intech19.enhanced.com> <20020604214100.GA6239@nevyn.them.org> <54d6v6wvfp.fsf@intech19.enhanced.com> <20020604223014.GA7579@nevyn.them.org> <547kldpbu0.fsf@intech19.enhanced.com> <20020605230537.GA4336@nevyn.them.org> From: Camm Maguire Date: Wed, 05 Jun 2002 17:21:00 -0000 In-Reply-To: Daniel Jacobowitz's message of "Wed, 5 Jun 2002 19:05:37 -0400" Message-ID: <54g001xnnf.fsf@intech19.enhanced.com> X-SW-Source: 2002-06/txt/msg00142.txt.bz2 Thanks as always. Forgot two more: Daniel Jacobowitz 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