Re: [Valgrind-developers] x86-64 attempts

[Jeremy F. <je...@go...>]

On Mon, 2004-07-26 at 10:35 +0100, Nicholas Nethercote wrote:
> On Sun, 25 Jul 2004, Jeremy Fitzhardinge wrote:
> 
> > Are you generating a x86-32 or -64 executable?  If the former, surely
> > you'd be using the same binutils as on a plain x86-32 machine?
> 
> x86-64.  I'm aiming just at running 64-bit code first, then I'll worry 
> about 32-bit code.  I'm not sure how much mixing of 32-bit and 64-bit code 
> is possible, that could become interesting.

Well, I think there's definite benefits in running 32-bit code in 64-bit
mode if available, because of all the extra address space and registers.

> On x86-64, 64-bit executable get mapped to 0x400000 -- that's only 4MB 
> above zero.  32-bit executables get mapped to 0x8048000 as on x86 but 
> libraries get loaded very low, eg. 0x552000.  So going below the 
> executable doesn't look feasible.

I hadn't realized it was that low.  But 4M is a lot of code - we can
easily fit stage2, a tool and libc into 4M (especially if we change all
the large static tables in core, memcheck and addrcheck to allocated
memory).

> > The VG_() stuff is somewhat redundant now, since nothing is "exported"
> > in the same way.  That is, we don't need to do name mangling to prevent
> > namespace clashes with the client libraries.
> 
> Why not?  I like the VG_() anyway as it marks the exported functions 
> clearly.

Well, with FV the client and Valgrind don't share a dynamic linker, so
their symbols are in entirely different namespaces.  The VG_() is from
the LD_PRELOAD days to stop Valgrind's symbol names from overlapping
with the clients.

By "export", what do you mean?  Exported to whom?  Mostly they're
internal; some are available for tool use, but there's no distinction
made in the naming - it just depends on which header file they're
declared in.

	J