> >>> Bu can't I just run valgrind on the MIPS CPU? Any hints on how to use > >>> valgrind? It's one of those tools I've been thing that I should > >>> explore, but never have.. > >>> > >> > >> I have no idea if you can run valgrind on that setup, just give it a > >> try maybe? If we're interested in finding invalid read/writes in > >> memory (ignoring leaks), the valgrind call would be basically this: > >> # G_SLICE=always-malloc valgrind --log-file=valgrind.log > >> /usr/sbin/ModemManager --debug > >> > >> The valgrind.log file would contain the errors reported. > > > > OK, that seemed too easy. Don't know how to progress here: > > > > root@finn:~# G_SLICE=always-malloc valgrind --log-file=valgrind.log > > /tmp/ModemManager --debug > > Illegal instruction > > Or maybe it wasn't? I should have looked at the log: > > root@finn:~# G_SLICE=always-malloc valgrind --log-file=/tmp/valgrind.log > /usr/sbin/ModemManager --debug > Illegal instruction > root@finn:~# cat /tmp/valgrind.log > ==7163== Memcheck, a memory error detector > ==7163== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==7163== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info > ==7163== Command: /usr/sbin/ModemManager --debug > ==7163== Parent PID: 4753 > ==7163== > ==7163== Conditional jump or move depends on uninitialised value(s) > ==7163== at 0x4079498: ??? (in /lib/libc.so) > ==7163== by 0x408A4CC: ??? (in /lib/libc.so) > ==7163== > ==7163== Conditional jump or move depends on uninitialised value(s) > ==7163== at 0x4078A7C: ??? (in /lib/libc.so) > ==7163== by 0x4078FA0: ??? (in /lib/libc.so) > ==7163== > vex mips->IR: unhandled instruction bytes: 0x65 0x80 0xDA 0x6 > ==7163== valgrind: Unrecognised instruction at address 0x4de9115. > ==7163== at 0x4DE9115: g_cache_insert (in /usr/lib/libglib-2.0.so.0.6800.1) > ==7163== by 0x4089440: ??? (in /lib/libc.so) > ==7163== Your program just tried to execute an instruction that Valgrind > ==7163== did not recognise. There are two possible reasons for this. > ==7163== 1. Your program has a bug and erroneously jumped to a non-code > ==7163== location. If you are running Memcheck and you just saw a > ==7163== warning about a bad jump, it's probably your program's fault. > ==7163== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==7163== i.e. it's Valgrind's fault. If you think this is the case or > ==7163== you are not sure, please let us know and we'll try to fix it. > ==7163== Either way, Valgrind will now raise a SIGILL signal which will > ==7163== probably kill your program. > ==7163== > ==7163== Process terminating with default action of signal 4 (SIGILL) > ==7163== Illegal opcode at address 0x4DE9115 > ==7163== at 0x4DE9115: g_cache_insert (in /usr/lib/libglib-2.0.so.0.6800.1) > ==7163== by 0x4089440: ??? (in /lib/libc.so) > ==7163== > ==7163== HEAP SUMMARY: > ==7163== in use at exit: 0 bytes in 0 blocks > ==7163== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > ==7163== > ==7163== All heap blocks were freed -- no leaks are possible > ==7163== > ==7163== Use --track-origins=yes to see where uninitialised values come from > ==7163== For lists of detected and suppressed errors, rerun with: -s > ==7163== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) > > > I guess this could point to the problem? Or just mean that only crazy > people run valgrind on MIPS ;-) >
I think it's the latter... :D Could be an endianness issue? that setup is BE right? -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel