|
From: Evan G. <th...@gm...> - 2008-08-28 02:39:05
|
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... |
|
From: Bart V. A. <bar...@gm...> - 2008-08-28 06:02:19
|
On Thu, Aug 28, 2008 at 4:39 AM, Evan Geller <th...@gm...> wrote: > 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. Is the source code of this port already publicly available ? Bart. |
|
From: Evan G. <th...@gm...> - 2008-08-28 06:18:29
|
No. Not yet. It's been my internship project for the past few months. I'll tar up my source tree and put it on a server by next friday for people to play with. I just want to tie up some loose ends. One warning though, it's not at all complete. It supports no floating point, no VFP (though it understands enough VFP to fake it so that setjmp and longjmp can do their context switches), clone() isn't implemented, there's bugs here and there, stack unwinding is really hacky (It works mostly with gcc generated code, up until the unwinder hits a variadic function), it only supports ARM, no thumb/thumbEE, etc, etc. However, I've had no problems running it on busybox. So, if you build for v4 with softfloat, most stuff should work. Maaaybe v6 since gcc seems to only like certain instructions like uxth/clz which are implemented. Anywho. I'll post it next week. /eazg On Aug 27, 2008, at 11:02 PM, Bart Van Assche wrote: > On Thu, Aug 28, 2008 at 4:39 AM, Evan Geller <th...@gm...> > wrote: >> 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. > > Is the source code of this port already publicly available ? > > Bart. |
|
From: Evan G. <th...@gm...> - 2008-08-28 15:44:05
|
On Aug 28, 2008, at 7:32 AM, Ivan Jager wrote: > On Wed, 27 Aug 2008, Evan Geller wrote: >> 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 > > Oh, you didn't tell me about this. In which cases is it broken? I'm not even sure any more. It took me a good week or so to get the flags right, they were a total pain haha. It wasn't your code that was broken I don't think, I think it was CAB's code that you converted into IR (some of the stuff you commented "this doesn't look right...") Plus, there was some stuff being passed to the helper itself (carry out, etc.) that wasn't being set right. > > >> removing the flag thunks slows things down. > > Oh :(, how much is it slowing things down? I would have expected it > to be faster than what was already there, given that VEX could > optimize it. I could change it so that VEX would optimize away the > flags that aren't being used. > > My reasoning for not using thunks was: 1. ARM instructions have an S > bit which indicates whether or not you want them to set the > condition codes, and gcc only sets this bit when they will be used. > and 2. Many ARM instructions only set some of the CCs, meaning that > the thunk method would need to force the previous thunk again for > those instructions. > > But, perhaps GCC's optimizer is so much better than VEX's that it's > still faster to make the C call and have an extra branch based on > CC_OP before getting to basically the same code. Well, it's not so much that the code itself runs slower, it's that VEX is forced to traverse a massive IR tree. When memcheck instruments a binary, it tries trace everything through each IROp, meaning the code gets inflated significantly, as well as memcheck having to trace through that massive IR tree. Memcheck is better at tracking through helpers since it can see the flag setting as one discrete operation. It was a definitely a good move to remove the thunk itself, since x86 tends to be [flag set] [flag set] [flag set] [check flags], whereas ARM is [flag set] [check flag] [check flag], but setting the flags in IR makes for a lot of duplicate code in the translation cache and a lot of stuff to traverse. Sorry about that first email not being too well thought out, I was about to miss my shuttle home when I saw Shachen's email, so I sorta banged it out. > > >> 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 > > Looking forward to seeing that, so I can do some testing. :) > > Ivan |
|
From: Cerion Armour-B. <ce...@va...> - 2008-08-29 20:18:26
|
Evan, Ivan, (& anyone else) If you've come across any code in valgrind that you think is broken, we'd appreciate your feedback... Cerion (CAB) On Thursday 28 Aug 2008, Evan Geller wrote: ... > I'm not even sure any more. It took me a good week or so to get the > flags right, they were a total pain haha. It wasn't your code that was > broken I don't think, I think it was CAB's code that you converted > into IR (some of the stuff you commented "this doesn't look right...") ... |
|
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 > > |