|
From: Xiachen D. <xia...@ho...> - 2008-08-25 20:32:22
|
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 _________________________________________________________________ |
|
From: Xiachen D. <xia...@ho...> - 2008-08-25 21:30:37
|
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 _________________________________________________________________ |
|
From: Nicholas N. <nj...@cs...> - 2008-09-16 00:44:55
|
On Mon, 25 Aug 2008, Xiachen Dong wrote: > 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; Also look at docs/internals/porting-to-ARM.txt and docs/internals/porting-HOWTO.txt. Note that they are out-of-date in some ways, but they might help. > 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? You're right, it should not require extra work on the tools. Nick |
|
From: Evan G. <th...@gm...> - 2008-09-16 01:31:01
|
It's not necessary. I posted a patch to the mailing list a little while ago that gives valgrind arm support. On Mon, Sep 15, 2008 at 5:44 PM, Nicholas Nethercote <nj...@cs...> wrote: > On Mon, 25 Aug 2008, Xiachen Dong wrote: > >> 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; > > Also look at docs/internals/porting-to-ARM.txt and > docs/internals/porting-HOWTO.txt. Note that they are out-of-date in some > ways, but they might help. > >> 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? > > You're right, it should not require extra work on the tools. > > Nick > > ------------------------------------------------------------------------- > 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 > -- --- Evan Geller th...@gm... |
|
From: Evan G. <th...@gm...> - 2008-09-16 01:31:22
|
On Mon, Sep 15, 2008 at 6:16 PM, Evan Geller <th...@gm...> wrote: > It's not necessary. I posted a patch to the mailing list a little while ago > that gives valgrind arm support. > > On Sep 15, 2008, at 5:44 PM, Nicholas Nethercote wrote: > >> On Mon, 25 Aug 2008, Xiachen Dong wrote: >> >>> 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; >> >> Also look at docs/internals/porting-to-ARM.txt and >> docs/internals/porting-HOWTO.txt. Note that they are out-of-date in some >> ways, but they might help. >> >>> 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? >> >> You're right, it should not require extra work on the tools. >> >> Nick >> >> ------------------------------------------------------------------------- >> 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 > > -- --- Evan Geller th...@gm... |