|
From: Nicholas N. <nj...@ca...> - 2003-08-14 09:56:30
|
On Thu, 14 Aug 2003 ps...@ic... wrote:
> I would really appreciate a feature being added to detect
> non-aligned access - i.e. could the valgrind VM halt if it
> reads or writes a 2-byte value from an odd address? or
> a 4-byte value from a non-4-aligned address? (or have an
> option to give a warning?)
>
> This is possibly a good feature for others as well - it
> can ensure portability of your code to the SPARC, for
> example.
It would absolutely have to be an option, since unaligned accesses are
valid on x86. I'm not convinced how useful this would be in general.
[aside: don't feel bad, if we included every feature ever requested into
Valgrind, it would have about 100 options]
However, it's easy to hack Valgrind yourself to abort when this happens.
In memcheck/mc_main.c, look for these functions:
MC_(helperc_LOADV4)()
MC_(helperc_LOADV2)()
MC_(helperc_STOREV4)()
MC_(helperc_STOREV4)()
One of them is called for every 4/2-byte memory read/write. You can
easily add a simple alignment check on the first argument ("a").
Something like this should work, for 2-byte accesses (warning, code not
tested):
if (a & 0x1 != 0) {
VG_(pp_ExeContext)(
VG_(get_ExeContext)(
VG_(get_current_or_recent_tid()
)
);
VG_(printf)("a = %p\n", a);
VG_(core_panic)("unaligned 2-byte access");
}
This code should work on the latest release, 20030725; I'm not sure about
earlier releases as some internal details have changed.
Hope this helps.
N
|
|
From: <ps...@ic...> - 2003-08-14 12:49:24
|
this is true however, our datasheet lists it as undefined-behavior, so to be safe i am assuming that undefined-behavior = worst-behavior-imaginable in any case i do actually have a suspicion that it corrupts the cache on this processor - so i want to rule this out the valgrind way. :-) -paul > In message <E19...@sc...> > ps...@ic... wrote: > > > However, the target platform (ARM) does not allow > > non-aligned short and int accesses. It also does not show > > up the error - the result of non-aligned access is cache > > corruption (ouch). > > I don't believe that the ARM will corrupt the cache if you do an > unaligned access but what it will do is load a wierd rotated value > that you won't be expecting. The behaviour is well defined, if a > little on the odd side, and truly sick people have been known to > write code that relies on it ;-) > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users --------------------------------------------- This message was sent using World Mail. http://www.worldonline.co.za |
|
From: Jeremy F. <je...@go...> - 2003-08-14 17:50:26
|
On Thu, 2003-08-14 at 02:44, Nicholas Nethercote wrote: > On Thu, 14 Aug 2003 ps...@ic... wrote: > > > I would really appreciate a feature being added to detect > > non-aligned access - i.e. could the valgrind VM halt if it > > reads or writes a 2-byte value from an odd address? or > > a 4-byte value from a non-4-aligned address? (or have an > > option to give a warning?) > > > > This is possibly a good feature for others as well - it > > can ensure portability of your code to the SPARC, for > > example. > > It would absolutely have to be an option, since unaligned accesses are > valid on x86. I'm not convinced how useful this would be in general. > > [aside: don't feel bad, if we included every feature ever requested into > Valgrind, it would have about 100 options] Lucky for us, so does the x86. There is a flag you can set in some register or other which makes the CPU trap on unaligned access. So long as we don't do it internally, you could set that and watch all the unaligned accesses in your program (even without Valgrind). J |
|
From: John R.
|
> Lucky for us, so does the x86. There is a flag you can set in some > register or other which makes the CPU trap on unaligned access. So long > as we don't do it internally, you could set that and watch all the > unaligned accesses in your program (even without Valgrind). Yes, it's the AC [Alignment Check] bit of the processor flags, which is bit 18 (the bit with positional value (1<<18) or 0x40000). It checks for unaligned access in user mode. $ cat foo.S _start: .globl _start pushf orl $1<<18,(%esp) popf movl 1(%esp),%eax nop $ gcc -o foo -nostartfiles -nostdlib foo.S $ gdb foo (gdb) run Program received signal SIGBUS, Bus error. 0x0804807d in _start () (gdb) x/i $pc 0x804807d <_start+9>: mov 0x1(%esp,1),%eax (gdb) q $ |
|
From: Zeljko V. <zel...@av...> - 2003-08-18 10:49:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Aug 14, 2003 at 11:29:44AM -0700, John Reiser wrote: > >Lucky for us, so does the x86. There is a flag you can set in some > >register or other which makes the CPU trap on unaligned access. So long > >as we don't do it internally, you could set that and watch all the > >unaligned accesses in your program (even without Valgrind). > > Yes, it's the AC [Alignment Check] bit of the processor flags, > which is bit 18 (the bit with positional value (1<<18) or 0x40000). > It checks for unaligned access in user mode. > But not only AC. As I recall, some other bit in some control register (CR) must be enabled also. And even then, AC occurs only in user mode (ring 3). - -- v Zeljko Vrba, dipl. ing. http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3B375F1C zel...@av... Advanced Simulation Technologies http://www.avl.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/QKw2zT2jbzs3XxwRAhUCAJ0dDXnGKC/OAxbGRYXg/HFufg21CACfXs78 /n9YBcjBGtSdVYUM3p+e790= =5Z3H -----END PGP SIGNATURE----- |
|
From: John R.
|
Zeljko Vrba wrote: > On Thu, Aug 14, 2003 at 11:29:44AM -0700, John Reiser wrote: > >>>Lucky for us, so does the x86. There is a flag you can set in some >>>register or other which makes the CPU trap on unaligned access. So long >>>as we don't do it internally, you could set that and watch all the >>>unaligned accesses in your program (even without Valgrind). >> >>Yes, it's the AC [Alignment Check] bit of the processor flags, >>which is bit 18 (the bit with positional value (1<<18) or 0x40000). >>It checks for unaligned access in user mode. >> > > But not only AC. As I recall, some other bit in some control register (CR) > must be enabled also. And even then, AC occurs only in user mode (ring 3). Did you try the example? It runs as expected in Linux 2.4.20, namely: generates SIGBUS for unaligned access from user mode (ring 3). So the AM bit (also bit 18, but in CR0) is enabled by the kernel. Valgrind (memcheck) applies only to user mode, so there is no additional restriction on this method of checking alignment of memory accesses. Even better, you can check any executable without recompilation: $ gdb a.elf (gdb) b main # any place you want to start checking (gdb) run Breakpoint 1 (gdb) set var $ps |= 1<<18 # set AlignmentCheck bit of eflags (gdb) continue and now gdb will catch SIGBUS for any unaligned access. To continue past each unaligned access: (gdb) handle SIGBUS nopass print stop # notify gdb+user, and not a.elf (gdb) set var $ps &= ~(1<<18) # clear AlignmentCheck bit of eflags (gdb) stepi # perform unaligned access (gdb) set var $ps |= (1<<18) # set AlignmentCheck bit of eflags (gdb) continue and those commands may be put into a gdb macro command for ease of use. |