Bug 869184 - trouble debugging 32bit program on ppc64 via valgrind gdb server
Summary: trouble debugging 32bit program on ppc64 via valgrind gdb server
Alias: None
Product: Red Hat Developer Toolset
Classification: Red Hat
Component: valgrind
Version: DTS 1.1 RHEL 6
Hardware: ppc64
OS: Linux
Target Milestone: rc
: 1.1
Assignee: Mark Wielaard
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2012-10-23 08:37 UTC by Miroslav Franc
Modified: 2016-02-01 02:27 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
Cause: The default (--vgdb=yes) valgrind gdbserver support is fairly lightweight, but might cause some registers and flags values to not always be up to date due to the optimisations done by the Valgrind core. Consequence: gdb is unable to show some parameters or variables on a breakpoint or when single stepping the program running under valgrind. Workaround (if any): Use valgrind --vgdb=full. Result: Better gdb debugging experience, but (much) slower program run under valgrind. See also the upstream manual as quoted in comment #2 with a somewhat subtler workaround for this particular case.
Clone Of:
Last Closed: 2012-10-29 22:26:01 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Miroslav Franc 2012-10-23 08:37:30 UTC
Description of problem:
I have trouble accessing variables when debugging -m32 compiled program with valgrind gdb server.  I was unable to reproduce with gdb-gdbserver, that's why I'm filing this against valgrind. Happens on both RHEL5 and RHEL6.

Version-Release number of selected component (if applicable):

How reproducible:

--- something.c ---
#include <stdio.h>

void f (int x);

main (int argc, char *argv[])
  int a;


  return 0;

f (int x)
  static int var __attribute__ ((used)) = 42;
    puts("hello, world");
--- something.c ---

Steps to Reproduce:
1. gcc -m32 -g something.c
2. valgrind --vgdb-error=0 ./a.out
3. gdb ./a.out
4. (gdb) target remote | vgdb
5. (gdb) b 10
6. (gdb) c

Actual results:
Breakpoint 1, main (argc=<error reading variable: Cannot access memory at address 0x18>, argv=<error reading variable: Cannot access memory at address 0x1c>) at something.c:10

Expected results:
Breakpoint 1, main (argc=1, argv=0xfffef1c4) at something.c:10

Comment 2 Mark Wielaard 2012-10-29 21:19:25 UTC
This seems to be caused by some optimizations done by the valgrind core when using the minimal gdbserver. See http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-limitations

"Processor registers and flags values.

When Valgrind gdbserver stops on an error, on a breakpoint or when single stepping, registers and flags values might not be always up to date due to the optimisations done by the Valgrind core. The default value --vex-iropt-register-updates=unwindregs-at-mem-access ensures that the registers needed to make a stack trace (typically PC/SP/FP) are up to date at each memory access (i.e. memory exception points). Disabling some optimisations using the following values will increase the precision of registers and flags values (a typical performance impact for memcheck is given for each option).

    --vex-iropt-register-updates=allregs-at-mem-access (+10%) ensures that all registers and flags are up to date at each memory access.
    --vex-iropt-register-updates=allregs-at-each-insn (+25%) ensures that all registers and flags are up to date at each instruction.

Note that --vgdb=full (+500%, see above Precision of "stop-at" commands) automatically activates --vex-iropt-register-updates=allregs-at-each-insn."

Using either --vex-iropt-register-updates=allregs-at-mem-access or --vgdb=full will make the example work as expected:

$ valgrind --vex-iropt-register-updates=allregs-at-mem-access --vgdb-error=0 ./a.out

$ gdb ./a.out
(gdb) target remote | vgdb
(gdb) b 10
Breakpoint 1 at 0x10000498: file something.c, line 10.
(gdb) c

Breakpoint 1, main (argc=1, argv=0xfeccf1e4) at something.c:10
10	  f(a);

Comment 3 Mark Wielaard 2012-10-29 21:22:09 UTC
Since this is a known limitation and has a known workaround, I suggest we just document this. Unless people think making --vex-iropt-register-updates=allregs-at-mem-access the default on ppc is a better idea (this would imply a 10% slowdown in the default case, so I am not recommending it).

Comment 4 RHEL Program Management 2012-10-29 22:26:01 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.