|
From: Paul M. <pa...@sa...> - 2004-04-23 07:35:05
|
I have recently found some time to work on getting my PPC port of Valgrind adapted to the current CVS version. I have put my current patch at: http://ozlabs.org/~paulus/valgrind-cvs-040423.patch.gz for people to look at if they are interested to see what I have changed. It is basically functioning but there are still some bugs left to be found, and there are parts of the code that are just a quick hack to get it working rather than the way I would like to see things done in the long run. Also, I haven't implemented core dumps for PPC, and vg_libpthread.c is going to need a lot more work. Areas where I have needed to modify things (apart from things I modified in the older patch against 2.1.0) include: * Stack management in the UME stuff. In particular the code relating to finding and modifying the aux vector needed some changes. * Code that deals with memory ranges. I have changed this to cope with ranges that end at 0xffffffff, since I have been working on this under a ppc64 kernel. * I had to change VG_(map_file_segment) so that it doesn't try to read symbols twice if it finds two mappings of a library which both have offset 0. Because vg_inject.so is relatively small, and ELF mappings on PPC use a 64kB alignment, both the text and the data mapping end up having offset 0. * Similarly I had to change the code which clears the BSS so that it clears the correct amount when the alignment specified in the ELF file (64kB on PPC) is different from the kernel page size. I'd like to continue the discussion about how Valgrind should be structured so as to support multiple architectures cleanly. I could make up some patches that would abstract a few things that are different between architectures - things like defining FIRST_ARCH_REG, LAST_ARCH_REG, etc. and using them instead of R_EAX, R_EDI, etc. Paul. |
|
From: Nicholas N. <nj...@ca...> - 2004-04-23 10:19:30
|
On Fri, 23 Apr 2004, Paul Mackerras wrote:
> I'd like to continue the discussion about how Valgrind should be
> structured so as to support multiple architectures cleanly. I could
> make up some patches that would abstract a few things that are
> different between architectures - things like defining FIRST_ARCH_REG,
> LAST_ARCH_REG, etc. and using them instead of R_EAX, R_EDI, etc.
It seems to me the factoring has two main parts -- all the UCode stuff,
and everything else. I think the UCode stuff is the difficult part,
requiring a lot of thinking; the rest is not so difficult... a
matter of coming up with a kind of API for the arch-specific bits.
I think someone just needs to sit down, go through all the bits where PPC
differs from x86, and try to factor it out. Paul, do you think you could
do this? You've undoubtedly got the best ideas about this anyway. If you
do, you could then show us what you did, for discussion.
I went through your port to see where these "API" differences were; this
was basically just looking for #ifdefs. I attach the rough summary list
below in case it's of any use.
N
- misc: regparms arg in C calls
asmlinkage ((regparms(n)))
want to have a function "Bool sane_instr_size(UInt
size)"
- vg_constants.h: VG_PATCHME_CALLSZ, VG_PATCHME_JMPSZ
- vg_include.h: VG_MAX_SPILLSLOTS,
VG_STACK_SIZE_W, VG_SIGSTACK_SIZE_W
regs in ThreadState
SET_THREAD_REG, etc
ppc has some extra variables, for hardware attributes
helpers for weird instructions
baseBlock layout
asmlinkage macro
lots of x86 specific codegen decls (PPC codegen simple
enough that mc_ppc_from_ucode.c doesn't need help from
vg_ppc_from_ucode.c, I think)
- vg_unistd.h: different syscall numbers [lots of files include
this file...]
- vg_kerneliface.h various types are different, yuk
- vg_skin.h: VG_MAX_REALREGS
UInstrs, CondCodes, Flag constants
Register numbers/names
- cg_main.c: getting cache stats
weird thing with Jcc when instrumenting?
- vg_errcontext.c: subtracting from return address to get previous instr
different regs for GDB attach
- vg_execontext.c: stack-walking slightly different (2 places)
- vg_libpthread.c: small inline asm statement different (2 places)
- vg_main.c: several baseBlock differences
- vg_mylibc.c: small inline asm
other minor things
- vg_proxylwp.c: various syscall/signal differences
- vg_scheduler.c: mostly register differences
some stack differences
- vg_signals.c: various horrid register/stack differences
- vg_symtab2.c: small register/ELF/instr length differences
- vg_syscalls.c: small register differences
no syscall arg blocks for PPC, all args in regs
some syscall implementation differences, yuk
- vg_translate.c: regnames[]
rank_to_realreg()/realreg_to_rank()
name_UCondcode()
vg_ppFlagSet()
UCode differences (saneUInstr(), name_UOpcode(),
pp_UInstrWorker(), get_reg_usage(),
containingArchRegOf(), maybe_uinstrReadsArchReg())
pp_realregs_liveness()
- vg_transtab.c: TT hash left-shifts PPC addrs by 2
flush_cache() added for PPC
helper_cache_inval() added for PPC
- hg_main.c: minor stack difference
- mc_main.c: helperc_LOADV[21]() differences, due to asm differences?
mc_{rd,wr}_[V42]_SLOWLY() -- several endian differences
compact/non-compact distinction
- mc_translate.c: some different TAGs
shifts/rotates instrumented differently
JMP instrumented differently
ADD has much more detail in PPC
extra UOps
N
|
|
From: Paul M. <pa...@sa...> - 2004-04-27 04:23:26
|
Nicholas Nethercote writes:
> I think someone just needs to sit down, go through all the bits where PPC
> differs from x86, and try to factor it out. Paul, do you think you could
> do this? You've undoubtedly got the best ideas about this anyway. If you
> do, you could then show us what you did, for discussion.
Sounds good. One question first though: where should I put
x86-specific bits? I notice that we have a coregrind/x86 directories
as well as coregrind/arch/x86-{linux,freebsd}. It's not clear to me
which files from those directories actually get used, or why the
platform/OS-specific directories are under an "arch" subdirectory when
the architecture-specific directory isn't.
Could someone enlighten me on what the intended design is here?
Thanks,
Paul.
|
|
From: Jeremy F. <je...@go...> - 2004-04-27 05:45:54
|
On Tue, 2004-04-27 at 14:21, Paul Mackerras wrote:
> Nicholas Nethercote writes:
>
> > I think someone just needs to sit down, go through all the bits where PPC
> > differs from x86, and try to factor it out. Paul, do you think you could
> > do this? You've undoubtedly got the best ideas about this anyway. If you
> > do, you could then show us what you did, for discussion.
>
> Sounds good. One question first though: where should I put
> x86-specific bits? I notice that we have a coregrind/x86 directories
> as well as coregrind/arch/x86-{linux,freebsd}. It's not clear to me
> which files from those directories actually get used, or why the
> platform/OS-specific directories are under an "arch" subdirectory when
> the architecture-specific directory isn't.
>
> Could someone enlighten me on what the intended design is here?
I've put a reasonable amount of thought into OS portability, but less
into CPU portability. This is mainly because one of the main
requirements for CPU portability be that the tools be mostly (ideally
entirely) CPU-independent. As you've pointed out though, this is pretty
tricky, especially when tools can add their own instrumentation
instructions to UCode.
Anyway, the intent is something like this:
coregrind/
arch/
<os>-<cpu>/
<os>-common/
unix-common/
common-<cpu>/
So, stuff which is inherently OS and CPU-specific (like syscall entry
conventions, signal handler details, ldt/iopl, etc) would go into
<os>-<cpu> directory; <os>-common is stuff which is, say, BSD or
Linux-specific, but CPU-independent; unix-common is stuff which is
absolutely generic (read/write/open/close syscall instrumentation, etc),
and common-<cpu> is stuff which is CPU-specific, but not OS-specific
(ie, most of vg_to/from_ucode, context-switching parts of vg_scheduler,
VCPU-init stuff in vg_main etc).
Does this make sense to you? I haven't gone through your most recent
patch in detail, but your comments look reasonable to me.
J
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-27 09:39:37
|
On Tue, 27 Apr 2004, Jeremy Fitzhardinge wrote: > Anyway, the intent is something like this: > > coregrind/ > arch/ > <os>-<cpu>/ > <os>-common/ > unix-common/ > common-<cpu>/ And the current structure is in a half-broken state, ie. we have an x86/ directory under coregrind/, and I think the x86-freebsd/ and x86-linux/ directories under arch/ aren't actually used at the moment. N |
|
From: Jeremy F. <je...@go...> - 2004-04-27 09:54:11
|
On Tue, 2004-04-27 at 19:39, Nicholas Nethercote wrote: > And the current structure is in a half-broken state, ie. we have an x86/ > directory under coregrind/, and I think the x86-freebsd/ and x86-linux/ > directories under arch/ aren't actually used at the moment. Yeah, coregrind/x86 was a half-arsed first attempt, but its contents should be moved under arch/. J |