|
From: Tom H. <to...@co...> - 2005-02-10 14:22:31
|
In message <169...@ka...>
Greg Parker <gp...@us...> wrote:
> Tom Hughes writes:
>
>> What's VGOS_() about? Your patch doesn't seem to define it.
>>
>> I assume it is for OS specific code, which is what VGA_() is for. Such
>> code should also go in the appropriate directory (coregrind/linux for
>> linux code).
>
> Yes, it is for OS-specific code. I was using different prefixes for
> OS-specific vs. CPU-specific vs. both. VGA_() isn't used much yet,
> so using VGOS_() for OS and VGA_() for CPU architecture seems like
> a good solution. However, it's still early to worry about that now,
> so either VG_() or VGA_() is fine for this code.
I noticed after I wrote the previous email that VGA_() seems to be
used for both OS specific, arch specific and OS+arch specific routines
and in fact isn't even used consistently then. I guess that's a result
of it being new.
We probably need to decide what the rule should be for new work
though - what was your intention what you starting splitting stuff
up Nick?
>> > * `int argc` is mishandled wrong on 64-bit platforms. Mac OS X writes a
>> > four-byte argc followed by a four-byte zero pad. I don't know what
>> > Linux does. This version is probably incorrect regardless.
>>
>> Well int is 4 bytes on 64 bit linux platforms, or at least on x86-64, so
>> it shouldn't need any padding. Is it 64 bits on the Mac?
>
> It's not the four-byte int that's the problem, but rather the eight-byte
> argv[0] immediately following it. On ppc64, the int is still four bytes,
> but argv[0] needs to be eight-byte aligned, and the stack frame needs to
> be 16-byte aligned, maybe more. So the four-byte int needs to be padded
> somehow, and I don't know whether it's the same on all systems.
So the actual value of the padding doesn't matter then, just that it
needs to be present. Presumably that is a general thing that int
arguments are padded to 8 bytes to ensure alignment of the next
argument if it is a pointer?
I believe the PPC support for valgrind is only ppc32 at the moment
anyway, or are you working on ppc64 support as well? If you are then
you probably need to be aware that the virtual CPU at the heart of
valgrind is being reworked at the moment.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|