|
From: Greg P. <gp...@us...> - 2005-02-10 13:33:21
|
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. > What slight issue is that auxv is probably ELF specific rather than > linux specific, at least in general. Some auxv entries may be linux > specific. Good point. One organization would be to call OS-specific code from the general implementation as done here, and then the OS-specific implementations could call a common ELF implementation, filtering out OS-specific entries as needed. Of course, parts of ELF are also processor-specific, which might throw another wrench into the works. > > * `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. -- Greg Parker gp...@us... |