|
From: Carl E. L. <ce...@li...> - 2014-04-04 17:05:04
|
On Fri, 2014-04-04 at 00:49 +0200, Julian Seward wrote:
> > also get warning from other window
> >
> > ==25684== Conditional jump or move depends on uninitialised value(s)
> > ==25684== at 0x40CA0D8: pthread_join (in /usr/lib64/libpthread-2.18.90.so)
> > ==25684== by 0x10000847: main (hg05_race2.c:31)
>
> Try running your test cases again with --track-origins=yes. That might shed
> some light on the issue.
>
> J
>
I have tried the --track-origins=yes option. It gives the following
==11785== Conditional jump or move depends on uninitialised value(s)
==11785== at 0x40CA0D8: pthread_join
(in /usr/lib64/libpthread-2.18.90.so)
==11785== by 0x10000847: main (hg05_race2.c:31)
==11785== Uninitialised value was created by a stack allocation
==11785== at 0x4002754: dl_main (in /usr/lib64/ld-2.18.90.so)
I stopped at the beginning of the stack allocation code and printed the
registers;
(gdb) info reg
r0 0x4020d30 67243312
r1 0xfff00eea0 68702760608
r2 0x4048000 67403776
r3 0x10000040 268435520
r4 0x9 9
r5 0xfff00eec0 68702760640
r6 0xfff00f600 68702762496
r7 0x7f7f7f7f7f7f7f7f 9187201950435737471
r8 0x65776f70002b3772 7311435046889142130
r9 0x0 0
r10 0xc 12
r11 0x8080808080808080 9259542123273814144
r12 0x40026f0 67118832
r13 0x0 0
r14 0x0 0
r15 0x0 0
r16 0x0 0
r17 0x7fff9000 2147454976
r18 0xffffffff 4294967295
r19 0xfff00ef90 68702760848
r20 0x80001000 2147487744
r21 0x4000390 67109776
r22 0x1 1
r23 0x1 1
r24 0x4038000 67338240
r25 0x10000 65536
r26 0x100005a0 268436896
r27 0x0 0
r28 0x10000040 268435520
r29 0x9 9
r30 0x40026f0 67118832
r31 0x403f9d8 67369432
pc 0x0 0x0
msr 0x0 0
cr 0x0 0
lr 0x0 0x0
ctr 0x0 0
xer 0x0 0
orig_r3 0x0 0
trap 0x0 0
r0s1 0x0 0
r1s1 0x0 0
r2s1 0x0 0
r3s1 0x0 0
r4s1 0x0 0
r5s1 0x0 0
r6s1 0x0 0followed by the address and a length.
r7s1 0x0 0
r8s1 0x0 0
r9s1 0x0 0
r10s1 0x0 0
r11s1 0x0 0
r12s1 0x0 0
r13s1 0x0 0
pcs1 0x0 0x0
msrs1 0x0 0
crs1 0x0 0
lrs1 0x0 0x0
ctrs1 0x0 0
xers1 0x0 0
r0s2 0x0 0
r1s2 0x0 0
r2s2 0x0 0
r3s2 0x0 0
r4s2 0x0 0
r5s2 0x0 0
r6s2 0x0 0
r7s2 0x0 0
r8s2 0x0 0
r9s2 0x0 0
r10s2 0x0 0
r11s2 0x0 0
r12s2 0x0 0
r13s2 0x0 0
r14s2 0x0 0
r15s2 0x0 0
r16s2 0x0 0
r17s2 0x0 0
r18s2 0x0 0
r19s2 0x0 0
r20s2 0x0 0
r21s2 0x0 0
r22s2 0x0 0
r23s2 0x0 0
r24s2 0x0 0
r25s2 0x0 0
r26s2 0x0 0
r27s2 0x0 0
r28s2 0x0 0
r29s2 0x0 0
r30s2 0x0 0
r31s2 0x0 0
pcs2 0x0 0x0
msrs2 0x0 0followed by the address and a length.
crs2 0x0 0
lrs2 0x0 0x0
ctrs2 0x0 0
xers2 0x0 0
The contents of the registers all appear to be valid. Here is the code
from gdb (edited to make it easier to read)
0x40026f0 <dl_main>: addis r2,r12,4
=> 0x40026f4 <dl_main+4>: addi r2,r2,22800
=> 0x40026f8 <dl_main+8>: mflr r0
=> 0x40026fc <dl_main+12>: addis r7,r2,-1
=> 0x4002700 <dl_main+16>: mfcr r12
=> 0x4002704 <dl_main+20>: std r14,-144(r1)
=> 0x4002708 <dl_main+24>: std r15,-136(r1)
=> 0x400270c <dl_main+28>: std r16,-128(r1)
=> 0x4002710 <dl_main+32>: std r17,-120(r1)
=> 0x4002714 <dl_main+36>: std r18,-112(r1)
=> 0x4002718 <dl_main+40>: std r19,-104(r1)
=> 0x400271c <dl_main+44>: std r20,-96(r1)
=> 0x4002720 <dl_main+48>: std r21,-88(r1)
=> 0x4002724 <dl_main+52>: std r0,16(r1)
=> 0x4002728 <dl_main+56>: std r22,-80(r1)
=> 0x400272c <dl_main+60>: std r23,-72(r1)
=> 0x4002730 <dl_main+64>: std r24,-64(r1)
=> 0x4002734 <dl_main+68>: std r26,-48(r1)
=> 0x4002738 <dl_main+72>: std r27,-40(r1)
=> 0x400273c <dl_main+76>: std r28,-32(r1)
=> 0x4002740 <dl_main+80>: std r29,-24(r1)
=> 0x4002744 <dl_main+84>: std r30,-16(r1)
=> 0x4002748 <dl_main+88>: std r31,-8(r1)
=> 0x400274c <dl_main+92>: std r25,-56(r1)
=> 0x4002750 <dl_main+96>: stw r12,8(r1)
=> 0x4002754 <dl_main+100>: stdu r1,-480(r1)
=> 0x4002758 <dl_main+104>: lwz r9,32328(r7)
I double checked the registers (s1 and s2) right before executing the stdu
instruction at 0x4002754 The registers were still are all zeros. I verified
the correct values were in r1 and in the memory location.
1: x/i $pc
=> 0x4002754 <dl_main+100>: stdu r1,-480(r1)
we have in r1
r1 0xfff00eea0 68702760608
The address to store at is
-480(r1) = -xfff00ecc0
x 0xfff00ecc0
0xfff00ecc0: 0xff00eea0
gdb) si
0x0000000004002758 in dl_main () from /lib64/ld64.so.2
1: x/i $pc
=> 0x4002758 <dl_main+104>: lwz r9,32328(r7)
the updated value in r1 is
r1 0xfff00ecc0 68702760128
r1s1 0x0 0
r1s2 0x0 0
the stdu instruction calculates the effective address and stores r1 in the
effective address then updates r1 to the effective address. Looks like r1
was correctly updated and the value in memory is correctly updated.
I tried to print the V bits for the memory location using the command
"get_vbits <addr> [<len>]". GDB just says "unknown command". I don't see
anything about having to use an additional command line option to enable
the get_vbits. Don't see anything in the documentation about having to do
something to enable it. Is there another way to print the V-bits of memory?
I spent some more time trying to locate where the check of the vbits occurs
when the instruction at address 0x40CA0D8 executes and thus triggers the
warning message. It looks like complainIfUndefined() in mc_translate.c might
be where the check gets done. It appears the routine gets the vbits and sets fn
to a helper function. The helper function calls MC_(record_cond_error) in
mc_main.c which appears to decide if the error is to be reported. But I still
seem to be missing exactly where the check is done that triggers the generation
of the error message. It might be helpful if I could find where the vbit check
detects the issue.
Thanks for your time and help.
Carl Love
|