|
From: Evan G. <Eva...@pa...> - 2008-09-08 04:23:16
Attachments:
valgrind-arm.patch.bz2
|
So, here's the ARM support patch for Valgrind. It's pretty incomplete, but it will run some basic applications. Here are some of the known issues, first the more apparent ones: * No floating point, VFP, or neon support. This can be compiled around. * Random instructions aren't implemented, or are partially implemented. Hence you might see a "long multiply accumulate is unsupported." You're welcome to implement them :) * Some bugs in memcheck. The suppressions file just isn't being read. I'll look into this. Basically it results in a slew of ==1172== Conditional jump or move depends on uninitialised value(s) ==1172== at 0x100000000000: _dl_relocate_object (in /lib/ld-2.5.so) ==1172== by 0x100000000000: dl_main (in /lib/ld-2.5.so) These can be safely ignored. The second bug is the "0x100000000000," still working on that... * Stack unwinding is very hacky. If it hits a variadic function, or custom code, or anything like that, it will choke. Some of the more internal issues: * No test suites. Hehhh.... * Lots of random stubbed out stuff. * Not yet handling all the possible optimizations for all the addressing modes. Most just fall through to registers. * I mistakenly pulled the literal case from VEX. Really this isn't much of an issue since either we do a mov/orr/orr/orr or a load/branch... and neither are very good. What's /really/ needed for ARM is literal pool support in VEX. In other words, try to coerce the immediate into a rotated immediate, if that doesn't work, try and do it with a move-negate, (etc.), if all else fails, reserve a spot in the literal pool to hold the value, and generate a pc-relative load. When enough instructions are generated that the size of a the add/sub operand of a pc relative load of one of the previous pc-rel loads isn't big enough to refer to it's immediate in the lit pool, we spill out the literal pool and fix up the previous pc-relative loads to point into the pool. In the mean time, mov/orr/orr/orr isn't toooo bad. Anywho. Have fun guys! |
|
From: John R. <joh...@gm...> - 2008-09-09 14:56:27
|
Hi Evan - great to see you've done a lot of work on this! I've unfortunately not got around to trying it due to cross-compile issues (grr gen-offsets grr) and having broken my ARM environment... will remedy that soon. I think it's probably not worth bothering with most of the optimizations such as addressing modes. They're not going to give an order of magnitude improvement, and there's a lot of other stuff to fix first. PC-relative constant pools may also be a bit tricky. The absolute worst case on ARM is 4 instructions per 32 bit constant, but most cases can be reduced to 1-2 using rotation, as you say. Inline immediates also avoid a load-use-stall, so the performance difference won't actually be huge (sometimes better!) Anyway, just thought I'd add at least one voice of encouragement here :) I have a lot of things I'd like to run through Valgrind on ARM. 2008/9/8 Evan Geller <Eva...@pa...>: > So, here's the ARM support patch for Valgrind. It's pretty incomplete, but it will run some basic applications. Here are some of the known issues, first the more apparent ones: > > * No floating point, VFP, or neon support. This can be compiled around. > > * Random instructions aren't implemented, or are partially implemented. Hence you might see a "long multiply accumulate is unsupported." You're welcome to implement them :) > > * Some bugs in memcheck. The suppressions file just isn't being read. I'll look into this. Basically it results in a slew of > > ==1172== Conditional jump or move depends on uninitialised value(s) > ==1172== at 0x100000000000: _dl_relocate_object (in /lib/ld-2.5.so) > ==1172== by 0x100000000000: dl_main (in /lib/ld-2.5.so) > > These can be safely ignored. The second bug is the "0x100000000000," still working on that... > > * Stack unwinding is very hacky. If it hits a variadic function, or custom code, or anything like that, it will choke. > > Some of the more internal issues: > > * No test suites. Hehhh.... > > * Lots of random stubbed out stuff. > > * Not yet handling all the possible optimizations for all the addressing modes. Most just fall through to registers. > > * I mistakenly pulled the literal case from VEX. Really this isn't much of an issue since either we do a mov/orr/orr/orr or a load/branch... and neither are very good. What's /really/ needed for ARM is literal pool support in VEX. In other words, try to coerce the immediate into a rotated immediate, if that doesn't work, try and do it with a move-negate, (etc.), if all else fails, reserve a spot in the literal pool to hold the value, and generate a pc-relative load. When enough instructions are generated that the size of a the add/sub operand of a pc relative load of one of the previous pc-rel loads isn't big enough to refer to it's immediate in the lit pool, we spill out the literal pool and fix up the previous pc-relative loads to point into the pool. In the mean time, mov/orr/orr/orr isn't toooo bad. > > Anywho. Have fun guys! > > ------------------------------------------------------------------------- > 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 > > |
|
From: Bart V. A. <bar...@gm...> - 2008-09-09 15:12:46
|
On Tue, Sep 9, 2008 at 4:56 PM, John Ripley <joh...@gm...> wrote: > > Hi Evan - great to see you've done a lot of work on this! I've > unfortunately not got around to trying it due to cross-compile issues > (grr gen-offsets grr) and having broken my ARM environment... will > remedy that soon. There is a patch available that solves the trouble with genoffsets and cross-compilation. This patch will be applied at an appropriate time to the official VEX distribution. See also http://bugs.kde.org/show_bug.cgi?id=162295 for more information about this patch. Bart. |