Re: [Valgrind-developers] preliminary PPC patch against CVS valgrind

[Nicholas N. <nj...@ca...>]

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