This is the mail archive of the
mailing list for the Archer project.
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 <firstname.lastname@example.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.