Ok. Sorry, I overlooked it
GDB:
1.
(gdb) info reg
r0 0x4007148 67137864
r1 0x0 0
r2 0x49ba000 77307904
r3 0x49bd90c 77322508
r4 0x4015f78 67198840
r5 0x4006054 67133524
r6 0xa 10
r7 0x4006ac0 67136192
r8 0x24 36
r9 0x401602c 67199020
r10 0x7dbb6a48 2109434440
r11 0x7dbb6674 2109433460
r12 0x7dbb6678 2109433464
sp 0x7dbb6678 0x7dbb6678
lr 0x40054ec 67130604
pc 0x40054ec 0x40054ec
cpsr 0x20000010 536870928
(gdb) x/9i $pc-4*4
0x40054dc: beq 0x40054ec
0x40054e0: ldr r2, [r7]
0x40054e4: add r3, r3, r2
0x40054e8: blx r3
=> 0x40054ec: mov r0, r7
0x40054f0: bl 0x4001440
0x40054f4: b 0x40054b8
0x40054f8: ldr r1, [r6, #88] ; 0x58
0x40054fc: sub sp, sp, #16
2.
(gdb) info reg
r0 0x7dbb6d21 2109435169
r1 0x4a2b000 77770752
r2 0x10680 67200
r3 0x4a2f494 77788308
r4 0x7dbb6d03 2109435139
r5 0x104d8 66776
r6 0x7dbb6a60 2109434464
r7 0x8 8
r8 0x0 0
r9 0x0 0
r10 0x4015f78 67198840
r11 0x7dbb6a4c 2109434444
r12 0x7dbb6a50 2109434448
sp 0x7dbb6a50 0x7dbb6a50
lr 0x4a15cd4 77683924
pc 0x4a15cd4 0x4a15cd4
cpsr 0x20000010 536870928
(gdb) x/9i $pc-4*4
0x4a15cc4: add r3, pc, r3
0x4a15cc8: str r2, [r3]
0x4a15ccc: beq 0x4a15cd4
0x4a15cd0: blx r5
=> 0x4a15cd4: bl 0x49ddf00
0x4a15cd8: ldr r3, [pc, #288] ; 0x4a15e00
0x4a15cdc: ldr r2, [sp]
0x4a15ce0: ldr r3, [r2, r3]
0x4a15ce4: cmp r3, #0
3.
(gdb) info reg
r0 0x207d8 133080
r1 0x1 1
r2 0x0 0
r3 0x10680 67200
r4 0x4a2b000 77770752
r5 0x0 0
r6 0x7dbb6a60 2109434464
r7 0x4a2b400 77771776
r8 0x0 0
r9 0x0 0
r10 0x4015f78 67198840
r11 0x7dbb6a2c 2109434412
r12 0x7dbb6a30 2109434416
sp 0x7dbb6a30 0x7dbb6a30
lr 0x4a15ac0 77683392
pc 0x4a15ac0 0x4a15ac0
cpsr 0x20000010 536870928
(gdb) x/9i $pc-4*4
0x4a15ab0: ldr r3, [r3]
0x4a15ab4: cmp r3, #0
0x4a15ab8: beq 0x4a15ac0
0x4a15abc: blx r3
=> 0x4a15ac0: ldr r3, [pc, #24] ; 0x4a15ae0
0x4a15ac4: add r3, pc, r3
0x4a15ac8: ldr r3, [r3]
0x4a15acc: cmp r3, #0
0x4a15ad0: popeq {r4, pc}
4.
(gdb) info reg
r0 0x482778c 75659148
r1 0x1 1
r2 0x4817000 75591680
r3 0x4817678 75593336
r4 0x4006178 67133816
r5 0x0 0
r6 0x4016034 67199028
r7 0x401602c 67199020
r8 0x0 0
r9 0x0 0
r10 0x4015f78 67198840
r11 0x7dbb6a1c 2109434396
r12 0x7dbb6a20 2109434400
sp 0x7dbb6a20 0x7dbb6a20
lr 0x4000e54 67112532
pc 0x4000e54 0x4000e54
cpsr 0x20000010 536870928
(gdb) x/9i $pc-4*4
0x4000e44: beq 0x4000e54
0x4000e48: ldr r2, [r4]
0x4000e4c: add r3, r3, r2
0x4000e50: blx r3
=> 0x4000e54: add r5, r5, #1
0x4000e58: b 0x4000e0c
0x4000e5c: pop {r4, r5, r6, r7, r11, pc}
0x4000e60: andeq r5, r1, r8, lsr #4
0x4000e64: andeq r5, r1, r12, lsl r2
Corresponding GDB server messages:
1.
==4996== Invalid read of size 4
==4996== at 0x40054EC: ??? (in /lib/ld-uClibc-0.9.33.2.so)
==4996== Address 0x7dbb6664 is on thread 1's stack
==4996== 20 bytes below stack pointer
2.
==4996== Invalid read of size 4
==4996== at 0x4A15CD4: ??? (in /lib/libuClibc-0.9.33.2.so)
==4996== Address 0x7dbb6a3c is on thread 1's stack
==4996== 20 bytes below stack pointer
3.
==4996== Invalid read of size 4
==4996== at 0x4A15AC0: ??? (in /lib/libuClibc-0.9.33.2.so)
==4996== Address 0x7dbb6a1c is on thread 1's stack
==4996== 20 bytes below stack pointer
4.
==4996== Invalid read of size 4
==4996== at 0x4000E54: ??? (in /lib/ld-uClibc-0.9.33.2.so)
==4996== Address 0x7dbb6a0c is on thread 1's stack
==4996== 20 bytes below stack pointer
uname -a:
Linux XXX 3.18.23 #6 SMP Tue Jul 11 16:35:20 CEST 2017 armv7l GNU/Linux
readelf --segments /bin/true | grep interpreter:
[Requesting program interpreter: /lib/ld-uClibc.so.0]
Changing uClibc package to compile with debugging symbols can result in
rebuilding whole buildroot and reflashing my embedded device. It could last
a few days, so I think that it will be last step I will take if any of
solutions won't work.
2017-09-02 14:14 GMT+02:00 John Reiser <jrei...@bitwagon.com>:
> From valgrind(memcheck):
>
>> ==2418== Invalid read of size 4
>> ==2418== at 0x40054EC: ??? (in /lib/ld-uClibc-0.9.33.2.so)
>> ==2418== Address 0x7d87a664 is on thread 1's stack
>> ==2418== 20 bytes below stack pointer
>>
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
>> 0x040054ec in ?? ()
>>
>
> From the vgdb server:
>
>> (gdb) info reg
>>
>
> r10 0x7d87aa48 2106042952
>> r11 0x7d87a674 2106041972
>> r12 0x7d87a678 2106041976
>> sp 0x7d87a678 0x7d87a678
>>
>
> pc 0x40054ec 0x40054ec
>>
>
> So the description "20 bytes below stack pointer" is correct,
> because ($sp - 0x7d87a664) = (0x7d87a678 - 0x7d87a664) = 0x14 = 20.
>
> What was the instruction stream? Where is the output from
> the next command that was requested in my earlier message:
> (gdb) x/9i $pc-4*4
>
> If the instruction at 0x040054ec is a 'ldr' fetch from memory
> which uses address -996(r10), -16(r11), -20(r12), or -20(sp),
> then that is the culprit, and it is a compiler error (or a logic
> error if indexing an array with an index less than zero,
> or a programmer error if the code was inlined assembly language.)
>
> Also, were you able to install the debuginfo symbols for /lib/
> ld-uClibc-0.9.33.2.so ?
> (or, not strip the symbols from ld-uClibc ?)
> It would be nice to correlate the instruction stream with the source code:
> (gdb) bt
> which should show function names, source file names, and line numbers.
> This would make it easier to confirm the exact cause of the error.
>
>
> --
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
