This is the mail archive of the archer@sourceware.org mailing list for the Archer 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: Initial psymtab replacement results


On Thu, Dec 17, 2009 at 08:38:52AM -0800, Paul Pluzhnikov wrote:
> On Mon, Dec 14, 2009 at 3:09 PM, Daniel Jacobowitz <drow@false.org> wrote:
> 
> >?Mappable data structures are
> > tricky; one thing I'd definitely insist on is host neutrality. ?IMO
> > that is not optional.
> 
> I am sorry for being slow, but I thought about it for a while and I
> still can't come up with a realistic scenario where the host
> non-neutrality of the cache matters.
> 
> Are you worried about hosts A and B (with different architecture) both
> NFS-mounting server:/usr/lib/debug ?  That already wouldn't work,
> since e.g. libc-X.Y.Z.so.debug is not host-neutral.

You obviously use a lot of native toolchains :-)  In GDB terms,
libc-X.Y.Z.so is host neutral.  It's not target neutral.  The terms
shift if you're talking about building glibc; build/host aren't a
great match for this scenario.

If I'm going to ship pre-cached ARM Linux files, I need them to work
on x86-linux and x86-mingw32 at a minimum.  Sometimes I need them to
work on sparc-solaris2.10 or powerpc-linux or arm-linux.  That's where
I was coming from.

If we can limit it to endianness, and maybe pointer size, then we can
put that in the cache key as Frank suggested.  Then this goes away, or
at least doesn't bother me so much.

-- 
Daniel Jacobowitz
CodeSourcery


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