Re: maxima: debugging unaligned access
On 1/18/10 10:23 AM, Camm Maguire wrote:
Greetings!
maxima succeeds at -O0 and fails at -O2 with the following unaligned
access kernel message:
Running tests in rtest13s: 17/17 tests passed.
Running tests in rtest14: 358/358 tests passed.
Running tests in rtest15: 250/250 tests passed.
Running tests in rtest16: maxima(18049): unaligned access to 0x60000000041291d8, ip=0x2000000000821e70
maxima(18049): unaligned access to 0x60000000041294c8, ip=0x2000000000821e70
regression testing ruleset
....
Is there anything I can do to chase this down?
Take care,
Run it under GDB.
See if you can do something like
gdb ./rtest16
start
disass 0x2000000000821e70
For example, here is a program of mine that has an unaligned access:
$ dmesg | tail -1
c-api-test-debu(7849): unaligned access to 0x2000000002f0003c, ip=0x2000000000232750
$ gdb ./c-api-test-debug
GNU gdb Fedora (6.8-3.fc9)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "ia64-redhat-linux-gnu"...
(gdb) start
Breakpoint 1 at 0x4000000000009ec0: file c-api-test.c, line 1118.
Starting program: /home/lynx/working/High/sitefilter-lib/src/c-api-test-debug
[Thread debugging using libthread_db enabled]
[New Thread 0x2000000001582890 (LWP 10959)]
[Switching to Thread 0x2000000001582890 (LWP 10959)]
main () at c-api-test.c:1118
1118 do_setup_debug(1);
Missing separate debuginfos, use: debuginfo-install curl.ia64 cyrus-sasl.ia64 e2fsprogs.ia64 glibc.ia64 keyutils.ia64 krb5.ia64 libidn.ia64 libselinux.ia64 nspr.ia64 openldap.ia64 openssl.ia64 zlib.ia64
(gdb) disass 0x2000000000232750
Dump of assembler code for function _ZNK5eSoft10le_int64_tcvlEv:
0x2000000000232720 <_ZNK5eSoft10le_int64_tcvlEv+0>: [MII] alloc r34=ar.pfs,6,5,0
0x2000000000232721 <_ZNK5eSoft10le_int64_tcvlEv+1>: mov r35=r12
0x2000000000232722 <_ZNK5eSoft10le_int64_tcvlEv+2>: adds r12=-16,r12
0x2000000000232730 <_ZNK5eSoft10le_int64_tcvlEv+16>: [MII] nop.m 0x0
0x2000000000232731 <_ZNK5eSoft10le_int64_tcvlEv+17>: mov r33=b0
0x2000000000232732 <_ZNK5eSoft10le_int64_tcvlEv+18>: mov r36=r1;;
0x2000000000232740 <_ZNK5eSoft10le_int64_tcvlEv+32>: [MMI] st8 [r35]=r32
0x2000000000232741 <_ZNK5eSoft10le_int64_tcvlEv+33>: ld8 r14=[r35]
0x2000000000232742 <_ZNK5eSoft10le_int64_tcvlEv+34>: nop.i 0x0;;
0x2000000000232750 <_ZNK5eSoft10le_int64_tcvlEv+48>: [MMI] ld8 r14=[r14];;
0x2000000000232751 <_ZNK5eSoft10le_int64_tcvlEv+49>: mov r37=r14
0x2000000000232752 <_ZNK5eSoft10le_int64_tcvlEv+50>: nop.i 0x0
0x2000000000232760 <_ZNK5eSoft10le_int64_tcvlEv+64>: [MIB] nop.m 0x0
0x2000000000232761 <_ZNK5eSoft10le_int64_tcvlEv+65>: nop.i 0x0
0x2000000000232762 <_ZNK5eSoft10le_int64_tcvlEv+66>: br.call.sptk.many b0=0x2000000000133ca0 <_ZN5eSoft10le_int64_t5bswapEl>
0x2000000000232770 <_ZNK5eSoft10le_int64_tcvlEv+80>: [MII] mov r1=r36
0x2000000000232771 <_ZNK5eSoft10le_int64_tcvlEv+81>: mov r14=r8;;
0x2000000000232772 <_ZNK5eSoft10le_int64_tcvlEv+82>: mov r8=r14
0x2000000000232780 <_ZNK5eSoft10le_int64_tcvlEv+96>: [MII] nop.m 0x0
0x2000000000232781 <_ZNK5eSoft10le_int64_tcvlEv+97>: mov.i ar.pfs=r34
0x2000000000232782 <_ZNK5eSoft10le_int64_tcvlEv+98>: mov b0=r33
0x2000000000232790 <_ZNK5eSoft10le_int64_tcvlEv+112>: [MIB] mov r12=r35
0x2000000000232791 <_ZNK5eSoft10le_int64_tcvlEv+113>: nop.i 0x0
0x2000000000232792 <_ZNK5eSoft10le_int64_tcvlEv+114>: br.ret.sptk.many b0;;
End of assembler dump.
(gdb)
You can see that the name of the function is
_ZNK5eSoft10le_int64_tcvlEv. You can find its C++ demangled name with
c++filt like this:
$ echo _ZNK5eSoft10le_int64_tcvlEv | c++filt
eSoft::le_int64_t::operator long() const
Now, in an optimized build this function gets inlined and disappears.
When that happens the only clue is the disassembly. In this case the
entire function pretty much compiles into the data load and the byte
swap. Actually even the byte swap disappears since IA64 is using LE
integers.
The offending instructions in this case are:
mov r35=r12
...
ld8 r14=[r35]
...
ld8 r14=[r14];;
and the pointer value loaded into r14 from *r35 and *r12 is not aligned
for a 8 byte load.
--
Zan Lynx
zlynx@acm.org
"Knowledge is Power. Power Corrupts. Study Hard. Be Evil."
Reply to: