From: John R. <joh...@gm...> - 2008-08-31 23:17:24
|
Fantastic news (just got round to catching up on the list). I was having a look at doing an ARM port about 6 months ago, but other work took priority. I guess I'll cross it off my list of things to consider doing if you're as close to completion as you suggest :) I'm looking forward to seeing the code when you submit it. I've got a lot of code I run on ARM I'd really like to run through Valgrind. 2008/8/28 Evan Geller <th...@gm...>: > My port is nearly done, minus floating point and VFP and neon and some other > stuff, but it runs plenty of stuff just fine. Yes memcheck works fine too. > Please don't start a port now :) It'd be a shame to have two separate ARM > ports. > > And for the record it's a huge amount of work. Ivan's code isn't working > either, since the flags aren't being set properly, and removing the flag > thunks slows things down. Currently the flags are being calculated in IR but > I plan to make that a helper. The tree is pretty dirty right now, I might > just post a tarball somewhere so people can play with it. I haven't really > talked to anyone from the valgrind project about actually integrating it in. > The code is just really hashy right now, but it works. I'll try and have it > up by next friday :-D > > /eazg > > ~~~~ > > Hi all: > > We are also trying to port Valgrind to ARM. We are not sure whether we shall > proceed because right now we have no idea how much time it is going to take. > I've read the following Documentation: > > 1) Valgrind: A Framework for Heavyweight Dynamic Binary Instrumentation; > 2) How to Shadow Every Byte of Memory Used by a Program; > > Here's my understanding and questions about porting Valgrind to ARM. Please > correct me if I am wrong: > > How Valgrind works: Valgrind core will first convert the user executable > into a standard Valgrind intermediate code (somewhat similar to the JAVA > byte code). After that, Valgrind will do some optimization on the > intermediate code. Then the Valgrind tools such as memcheck will instrument > (massage) the intermediate code to implement the tools' own functionality, > e.g., memory leak detection. Since this step is based on intermediate code > (architecture independent), theoretically, we don't need to do extra work on > Valgrind tools. When Valgrind tools finish massaging the intermediate code, > Valgrind core will optimize the intermediate code again, allocate > architecture dependant registers, and then convert the optimized > intermediate code back to the architecture specific machine code (ARM binary > code). To port Valgrind to ARM, we need to do the following: > a) Convert ARM executable to IR code. This part is already available > inVEX/priv/guest-arm/toIR.c and Ivan has the path for it. This is the > client's side. > b) Convert the optimized Valgrind intermediate code back to the ARM binary > executable. There's a lot of work to do here inVEX/priv/host-arm/hdefs.c. > Basically we have to implement corresponding functions for ARM as listed in > vex_main.c for PPC32: > > case VexArchPPC32: > mode64 = False; > getAllocableRegs_PPC ( &n_available_real_regs,&available_real_regs, mode64 > ); > isMove = (Bool(*)(HInstr*,HReg*,HReg*)) isMove_PPCInstr; > getRegUsage = (void(*)(HRegUsage*,HInstr*,Bool))getRegUsage_PPCInstr; > mapRegs = (void(*)(HRegRemap*,HInstr*,Bool)) mapRegs_PPCInstr; > genSpill = (HInstr*(*)(HReg,Int,Bool)) genSpill_PPC; > genReload = (HInstr*(*)(HReg,Int,Bool)) genReload_PPC; > ppInstr = (void(*)(HInstr*,Bool)) ppPPCInstr; > ppReg = (void(*)(HReg)) ppHRegPPC;iselSB = iselSB_PPC; > emit = (Int(*)(UChar*,Int,HInstr*,Bool,void*))emit_PPCInstr; > host_is_bigendian = True; > host_word_type = Ity_I32; > vassert(are_valid_hwcaps(VexArchPPC32, vta->archinfo_host.hwcaps)); > vassert(vta->dispatch == NULL); /* return-to-dispatcher scheme */ > break; > > Of course we need to implement other functions such as scheduler, > dispatcher, c_main startup code, etc..., but the above mentioned two parts > are the key steps to the porting. My biggest concern is that according to my > understanding, porting to ARM does not require extra work on memcheck, > callgrind, helgrind and other Valgrind tools since these tools work on > Valgrind IR code and the IR code is architecture independent. Can anyone > tell me whether the porting requires extra work on Valgrind tools? > > Thanks > Shachen > > > _________________________________________________________________ > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li...<mailto:Val...@li...> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > > -- > --- > Evan Geller > th...@gm... > > > -- > --- > Evan Geller > th...@gm... > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > |