[Bug gdb/15871] Unavailable entry value is not shown correctly

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=15871

--- Comment #9 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
CVSROOT:    /cvs/src
Module name:    src
Changes by:    palves@sourceware.org    2013-08-22 10:00:05

Modified files:
    gdb            : ChangeLog corefile.c target.c target.h 

Log message:
    PR gdb/15871: Unavailable entry value is not shown correctly

    In entry-values.exp, we have a test where the entry value of 'j' is
    unavailable, so it is expected that printing j@entry yields
    "<unavailable>".  However, the actual output is:

    (gdb) frame
    #0  0x0000000000400540 in foo (i=0, i@entry=2, j=2, j@entry=<error reading
variable: Cannot access memory at address 0x6009e8>)

    The error is thrown here:

    #0  throw_it (reason=RETURN_ERROR, error=MEMORY_ERROR, fmt=0x8cd550 "Cannot
access memory at address %s", ap=0x7fffffffc8e8) at
../../src/gdb/exceptions.c:373
    #1  0x00000000005e2f9c in throw_error (error=MEMORY_ERROR, fmt=0x8cd550
"Cannot access memory at address %s") at ../../src/gdb/exceptions.c:422
    #2  0x0000000000673a5f in memory_error (status=5, memaddr=6293992) at
../../src/gdb/corefile.c:204
    #3  0x0000000000673aea in read_memory (memaddr=6293992,
myaddr=0x7fffffffca60 "\200\316\377\377\377\177", len=4) at
../../src/gdb/corefile.c:223
    #4  0x00000000006784d1 in dwarf_expr_read_mem (baton=0x7fffffffcd50,
buf=0x7fffffffca60 "\200\316\377\377\377\177", addr=6293992, len=4) at
../../src/gdb/dwarf2loc.c:334
    #5  0x000000000067645e in execute_stack_op (ctx=0x1409480,
op_ptr=0x7fffffffce87 "\237<\005@", op_end=0x7fffffffce88 "<\005@") at
../../src/gdb/dwarf2expr.c:1045
    #6  0x0000000000674e29 in dwarf_expr_eval (ctx=0x1409480,
addr=0x7fffffffce80 "\003\350\t`", len=8) at ../../src/gdb/dwarf2expr.c:364
    #7  0x000000000067c5b2 in dwarf2_evaluate_loc_desc_full (type=0x10876d0,
frame=0xd8ecc0, data=0x7fffffffce80 "\003\350\t`", size=8, per_cu=0xf24c40,
byte_offset=0)
    at ../../src/gdb/dwarf2loc.c:2236
    #8  0x000000000067cc65 in dwarf2_evaluate_loc_desc (type=0x10876d0,
frame=0xd8ecc0, data=0x7fffffffce80 "\003\350\t`", size=8, per_cu=0xf24c40)
    at ../../src/gdb/dwarf2loc.c:2407
    #9  0x000000000067a5d4 in dwarf_entry_parameter_to_value
(parameter=0x13a7960, deref_size=18446744073709551615, type=0x10876d0,
caller_frame=0xd8ecc0, per_cu=0xf24c40)
    at ../../src/gdb/dwarf2loc.c:1160
    #10 0x000000000067a962 in value_of_dwarf_reg_entry (type=0x10876d0,
frame=0xd8de70, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at
../../src/gdb/dwarf2loc.c:1310
    #11 0x000000000067aaca in value_of_dwarf_block_entry (type=0x10876d0,
frame=0xd8de70, block=0xf1c2d4 "Q", block_len=1) at
../../src/gdb/dwarf2loc.c:1363
    #12 0x000000000067e7c9 in locexpr_read_variable_at_entry (symbol=0x13a7540,
frame=0xd8de70) at ../../src/gdb/dwarf2loc.c:3326
    #13 0x00000000005daab6 in read_frame_arg (sym=0x13a7540, frame=0xd8de70,
argp=0x7fffffffd0e0, entryargp=0x7fffffffd100) at ../../src/gdb/stack.c:362
    #14 0x00000000005db384 in print_frame_args (func=0x13a7470, frame=0xd8de70,
num=-1, stream=0xea3890) at ../../src/gdb/stack.c:669
    #15 0x00000000005dc338 in print_frame (frame=0xd8de70, print_level=1,
print_what=SRC_AND_LOC, print_args=1, sal=...) at ../../src/gdb/stack.c:1199
    #16 0x00000000005db8ee in print_frame_info (frame=0xd8de70, print_level=1,
print_what=SRC_AND_LOC, print_args=1) at ../../src/gdb/stack.c:851
    #17 0x00000000005da2bb in print_stack_frame (frame=0xd8de70, print_level=1,
print_what=SRC_AND_LOC) at ../../src/gdb/stack.c:169
    #18 0x00000000005de236 in frame_command (level_exp=0x0, from_tty=1) at
../../src/gdb/stack.c:2265

    dwarf2_evaluate_loc_desc_full (frame #7) knows to handle
    NOT_AVAILABLE_ERROR errors, but read_memory always throws
    a generic error.

    Presently, only the value machinery knows to handle unavailable
    memory.  We need to push the awareness down to the target_xfer layer,
    making it return a finer grained error indication.  We can only return
    a generic -1 nowadays, which leaves the upper layers with no clue on
    why the xfer failed.  Use target_xfer_partial directly, rather than
    propagating the error through target_read_memory so as to get a better
    address to display in the error message.

    (target_read_memory & friends build on top of target_read (thus the
    target_xfer machinery), but turn all errors to EIO, an errno value.  I
    think this is a mistake, and we'd better convert all these to return a
    target_xfer_error too, but that can be done separately.  I looked
    around a bit over memory_error calls, and the need to handle random
    errno values, other than the EIOs gdb itself hardcodes, probably comes
    (only) from deprecated_xfer_memory, which uses errno for error
    indication, but I didn't look exhaustively.  We should really get rid
    of deprecated_xfer_memory and of passing down errno values as error
    indication in target_read & friends methods).

    Tested on x86_64 Fedora 17, native and gdbserver.  Fixes the test in
    the PR, which will be added to the testsuite later.

    gdb/
    2013-08-22  Pedro Alves  <palves@redhat.com>

    PR gdb/15871
    * corefile.c (target_xfer_memory_error): New function.
    (memory_error): Defer EIO to target_memory_error.
    (read_memory): Use target_xfer_partial, and handle finer-grained
    target xfer errors.
    * target.c (target_xfer_error_to_string): New function.
    (memory_xfer_partial_1): If memory is known to be
    unavailable, return TARGET_XFER_E_UNAVAILABLE instead of -1.
    (target_xfer_partial): Make extern.
    * target.h (enum target_xfer_error): New enum.
    (target_xfer_error_to_string): Declare function.
    (target_xfer_partial): Declare function.
    (struct target_ops) <xfer_partial>: Adjust describing comment.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.15917&r2=1.15918
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/corefile.c.diff?cvsroot=src&r1=1.73&r2=1.74
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/target.c.diff?cvsroot=src&r1=1.344&r2=1.345
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/target.h.diff?cvsroot=src&r1=1.271&r2=1.272

-- 
You are receiving this mail because:
You are on the CC list for the bug.