[Valgrind-users] symbol resolution in valgrind

[Mathieu L. <mat...@gm...>]

hi,

I am trying to debug an application failing with an elf loader of
mine. Unsurprisingly, my code is buggy which leads to:

==7799== Conditional jump or move depends on uninitialised value(s)
==7799==    at 0x3F5D87F42D: (within /lib64/libc-2.10.1.so)
==7799==    by 0x3F5EC13133: (within /lib64/libselinux.so.1)
==7799==    by 0x4020E87: ???
==7799==    by 0x3F5D88892B: (within /lib64/libc-2.10.1.so)
==7799==    by 0x421224F: ???
==7799==    by 0x77: ???
==7799==    by 0x401116F: ???
==7799==    by 0x3F5EE1BD5F: (within /lib64/libselinux.so.1)
==7799==    by 0x7FEFFFF77: ???
==7903== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
==7903== starting debugger with cmd: /usr/bin/gdb -nw /proc/7904/fd/1014 7904
GNU gdb (GDB) Fedora (6.8.50.20090302-33.fc11)
Copyright (C) 2009 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 "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Attaching to program: /proc/7904/fd/1014, process 7904

[loading symbols]

strlen () at ../sysdeps/x86_64/strlen.S:40
40		jnz	1f
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:40
#1  0x0000003f5ec13134 in init_selinux_config () at selinux_config.c:166
#2  0x0000003f5ec15516 in __do_global_ctors_aux () from /lib64/libselinux.so.1
#3  0x0000003f5ec04c9b in _init () from /lib64/libselinux.so.1
#4  0x00000007ff000018 in ?? ()
#5  0x000000000400a3fe in call_init (file=0x4019cb0) at vdl-init-fini.c:88
#6  0x000000000400a4a3 in vdl_init_fini_call_init (files=0x4021af0) at
vdl-init-fini.c:111
#7  0x000000000400bb56 in stage2_initialize (input=
      {interpreter_load_base = 67108864, program_phdr = 0x400040,
program_phnum = 8, sysinfo = 0, program_argc = 1, program_argv =
0x7ff0002b8, program_envp = 0x7ff0002c8}) at stage2.c:327
#8  0x000000000400b059 in stage1 (input_output=0x7ff000290) at stage1.c:192
#9  0x000000000400bc8a in L1 () from ./ldso
#10 0x0000000000000000 in ?? ()
Current language:  auto; currently asm
(gdb) p $rip
$1 = (void (*)()) 0x3f5d87f42d <strlen+45>
(gdb) disas
Dump of assembler code for function strlen:
0x0000003f5d87f400 <strlen+0>:	mov    %rdi,%rcx
0x0000003f5d87f403 <strlen+3>:	mov    %rdi,%r8
0x0000003f5d87f406 <strlen+6>:	and    $0xfffffffffffffff0,%rdi
0x0000003f5d87f40a <strlen+10>:	pxor   %xmm1,%xmm1
0x0000003f5d87f40e <strlen+14>:	or     $0xffffffffffffffff,%esi
0x0000003f5d87f411 <strlen+17>:	movdqa (%rdi),%xmm0
0x0000003f5d87f415 <strlen+21>:	sub    %rdi,%rcx
0x0000003f5d87f418 <strlen+24>:	lea    0x10(%rdi),%rdi
0x0000003f5d87f41c <strlen+28>:	pcmpeqb %xmm1,%xmm0
0x0000003f5d87f420 <strlen+32>:	shl    %cl,%esi
0x0000003f5d87f422 <strlen+34>:	pmovmskb %xmm0,%edx
0x0000003f5d87f426 <strlen+38>:	xor    %eax,%eax
0x0000003f5d87f428 <strlen+40>:	neg    %r8
0x0000003f5d87f42b <strlen+43>:	and    %esi,%edx
0x0000003f5d87f42d <strlen+45>:	jne    0x3f5d87f443 <strlen+67>
0x0000003f5d87f42f <strlen+47>:	movdqa (%rdi),%xmm0
0x0000003f5d87f433 <strlen+51>:	lea    0x10(%rdi),%rdi
0x0000003f5d87f437 <strlen+55>:	pcmpeqb %xmm1,%xmm0
0x0000003f5d87f43b <strlen+59>:	pmovmskb %xmm0,%edx
0x0000003f5d87f43f <strlen+63>:	test   %edx,%edx
0x0000003f5d87f441 <strlen+65>:	je     0x3f5d87f42f <strlen+47>
0x0000003f5d87f443 <strlen+67>:	lea    -0x10(%rdi,%r8,1),%rdi
0x0000003f5d87f448 <strlen+72>:	bsf    %edx,%eax
0x0000003f5d87f44b <strlen+75>:	add    %rdi,%rax
0x0000003f5d87f44e <strlen+78>:	retq
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb)


The above looks like a jne instruction depending on unitialized value
in strlen called from init_selinux_config. It's not clear to me how it
could possibly depend on uninitialized data (maybe one of the 2
registers in "and %esi,%edx" is not initialized properly) but, well.
What I am really curious about is why the backtrace output by valgrind
does not show the symbolic names of my functions. Would someone mind
point me to the code in valgrind which performs symbol lookups so that
I can figure out what I need to do in my loader to make at least this
work ?

Mathieu
-- 
Mathieu Lacage <mat...@gm...>