I've stumbled on this by inspection.
When the TUI's register window is first displayed, it always shows the
registers of the current frame, instead of of the selected frame,
which is obviously bogus.
E.g.,
(gdb) step # into "function"
(gdb) up
(gdb) tui reg general # or C-x 2, C-x 2
shows the registers of "function", rather than the caller's.
A subsequent:
(gdb) frame
or
(gdb) down
(gdb) up
can be used as workaround to "fix" it.
gdb/
2013-09-05 Pedro Alves <palves@redhat.com>
PR tui/15933
* tui/tui-regs.c (tui_show_registers): Show registers of the
selected frame, not the current frame.
(queue_and_load_dwo_tu): New function.
(lookup_dwo_signatured_type): Set per_cu.tu_read.
(maybe_queue_comp_unit): Rename this_cu argument to dependent_cu.
Make dependent_cu optional.
(dw2_do_instantiate_symtab): If we just loaded a CU from a DWO,
and an older .gdb_index is in use, queue and load all its TUs too.
testsuite/
* gdb.base/enumval.c (ZERO): New enum value.
(main): Use it
* gdb.base/enumval.exp: Test ability to print ZERO.
gdb/
2013-09-04 Jan Kratochvil <jan.kratochvil@redhat.com>
Code cleanup: Change OPF_DISABLE_REALPATH to OPF_RETURN_REALPATH.
* cli/cli-cmds.c (find_and_open_script): Add OPF_RETURN_REALPATH to
variable search_flags.
* defs.h (OPF_DISABLE_REALPATH): Rename to ...
(OPF_RETURN_REALPATH): ... here.
* dwarf2read.c (try_open_dwop_file): Set OPF_RETURN_REALPATH for flags.
* exec.c (exec_file_attach): Remove OPF_DISABLE_REALPATH from openp
call. Twice.
* nto-tdep.c (nto_find_and_open_solib): Add OPF_RETURN_REALPATH for
openp call.
* solib.c (solib_find): Likewise. Four times.
* source.c (openp): Change OPF_DISABLE_REALPATH to OPF_RETURN_REALPATH
in the function comment and for the realpath_fptr variable.
(source_full_path_of): Add OPF_RETURN_REALPATH for openp call.
(find_and_open_source): Likewise. Twice.
* symfile.c (symfile_bfd_open): Likewise, also twice.
* config/tc-ppc.c (md_apply_fix): Handle defined after use toc
symbols.
gas/testsuite/
* gas/ppc/aix.exp: Run xcoff-toc-1 test.
* gas/ppc/xcoff-toc-1.s, gas/ppc/xcoff-toc-1.d: New test.
* config/tc-arm.c (T16_32_TAB): Add _udf.
(do_t_udf): New function.
(insns): Add "udf".
* gas/arm/udf-bad.s: New file.
* gas/arm/udf-bad.d: New file.
* gas/arm/udf-bad.l: New file.
* gas/arm/udf.s: New file.
* gas/arm/udf.d: New file.
* gas/arm/udf.l: New file.
* arm-dis.c (arm_opcodes): Add udf.
(thumb_opcodes): Use "udf" mnemonic rather than UNDEFINED_INSTRUCTION.
(thumb32_opcodes): Add udf.w.
(print_insn_thumb32): Handle %H as the thumb32_opcodes comment says.
Pedro Alves <palves@redhat.com>
* symfile.c (add_symbol_file_command): Error out on unknown
option. Handle EXPECTING_SEC_ADDR/EXPECTING_SEC_NAME before '-'
options and collapse into single conditional branch.
2013-09-13 Muhammad Bilal <mbilal@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdb.base/relocate.exp: Check that invalid options are
rejected.
2013-09-03 Pavel Chupin <pavel.v.chupin@intel.com>
PR gold/15927
* x86_64.cc (Target_x86_64<size>::Scan::global): Use relative
relocation for R_X86_64_32 on x32.
detach_fork.
* inf-ptrace.c (inf_ptrace_follow_fork): Likewise.
* inf-ttrace.c (inf_ttrace_follow_fork): Likewise.
* inferior.h (detach_fork): Remove.
* infrun.c (detach_fork): Adjust comment and make it
static.
(follow_fork): Pass detach_fork parameter to
target_follow_fork.
* linux-nat.c (linux_child_follow_fork): New parameter
detach_fork.
* target.c (target_follow_fork): New parameter detach_fork.
Pass detach_fork as parameter and print its value.
* target.h (struct target_ops) <to_follow_fork>: New int
parameter.
(target_follow_fork): New parameter detach_fork.
The field "bfd" no longer exists in struct target_section.
Use the_bfd_section->owner instead.
gdb/ChangeLog:
* solib-ia64-hpux.c (ia64_hpux_relocate_section_addresses):
Replace sec->bfd by sec->the_bfd_section->owner.
I'm seeing trace-buffer-size.exp failing (with gdbserver):
(gdb) PASS: gdb.trace/trace-buffer-size.exp: tstatus check 2
show trace-buffer-size 4
Requested size of trace buffer is 4.
(gdb) PASS: gdb.trace/trace-buffer-size.exp: show trace buffer size
set trace-buffer-size -1
memory clobbered past end of allocated block
Remote connection closed
(gdb) FAIL: gdb.trace/trace-buffer-size.exp: set trace buffer size 2
set trace-buffer-size unlimited
(gdb) PASS: gdb.trace/trace-buffer-size.exp: set trace-buffer-size unlimited
That "memory clobbered past end of allocated block" is mcheck triggering.
Valgrind shows:
==23624== Invalid write of size 1
==23624== at 0x418DD8: clear_trace_buffer (tracepoint.c:1443)
==23624== by 0x418F3A: init_trace_buffer (tracepoint.c:1497)
==23624== by 0x41D95B: cmd_bigqtbuffer_size (tracepoint.c:4061)
==23624== by 0x41DEEC: handle_tracepoint_general_set (tracepoint.c:4193)
clear_trace_buffer does:
static void
clear_trace_buffer (void)
{
trace_buffer_start = trace_buffer_lo;
trace_buffer_free = trace_buffer_lo;
trace_buffer_end_free = trace_buffer_hi;
trace_buffer_wrap = trace_buffer_hi;
/* A traceframe with zeroed fields marks the end of trace data. */
((struct traceframe *) trace_buffer_free)->tpnum = 0;
((struct traceframe *) trace_buffer_free)->data_size = 0;
traceframe_read_count = traceframe_write_count = 0;
traceframes_created = 0;
}
And the tpnum+data_size fields are over 4 bytes... This fixes it by
ensuring we allocate space at least for an EOB. We have code
elsewhere that relies on the EOB being present (like e.g.,
find_traceframe), so this seems simplest.
gdb/gdbserver/
2013-09-02 Pedro Alves <palves@redhat.com>
* tracepoint.c (TRACEFRAME_EOB_MARKER_SIZE): New macro.
(init_trace_buffer): Ensure at least TRACEFRAME_EOB_MARKER_SIZE is
allocated.
(trace_buffer_alloc): Use TRACEFRAME_EOB_MARKER_SIZE.
When I added gdb_read_memory, with bits factored out from elsewhere, I
missed adjusting this error return. gdb_read_memory has an interface
similar to Like GDB's xfer_partial:
> /* Read trace frame or inferior memory. Returns the number of bytes
> actually read, zero when no further transfer is possible, and -1 on
> error. Return of a positive value smaller than LEN does not
> indicate there's no more to be read, only the end of the transfer.
Returning EIO, a positive value, is obviously bogus, for the caller
will confuse it with a successful partial transfer.
Found by inspection.
Tested on x86_64 Fedora 17.
gdb/gdbserver/
2013-09-02 Pedro Alves <palves@redhat.com>
* server.c (gdb_read_memory): Return -1 on traceframe memory read
error instead of EIO.
* s390-opc.txt: Fix description for fiebra, fidbra, and fixbra.
For the load fp integer instructions only the suppression flag was
new with z196 version.
* NEWS: Add entry mentioning support for native Windows x64
SEH data.
* amd64-windows-tdep.c: #include "objfiles.h", "frame-unwind.h",
"coff/internal.h", "coff/i386.h", "coff/pe.h" and "libcoff.h".
(struct amd64_windows_frame_cache): New struct.
(amd64_windows_w2gdb_regnum): New global.
(pc_in_range, amd64_windows_frame_decode_epilogue)
(amd64_windows_frame_decode_insns, amd64_windows_find_unwind_info)
(amd64_windows_frame_cache, amd64_windows_frame_prev_register)
(amd64_windows_frame_this_id): New functions.
(amd64_windows_frame_unwind): New static global.
(amd64_windows_skip_prologue): New function.
(amd64_windows_init_abi): Call frame_unwind_prepend_unwinder
with amd64_windows_frame_unwind. Call set_gdbarch_skip_prologue
with amd64_windows_skip_prologue.
When I looked for print_stack_frame calls in MI, I wondered why this
one passing down SRC_AND_LOC. print_stack_frame does:
/* For mi, alway print location and address. */
if (ui_out_is_mi_like_p (current_uiout))
print_what = LOC_AND_ADDRESS;
So it really doesn't matter which value is passed down, but, to avoid
confusion in readers, it's better to use the MI standard here.
There's another SRC_AND_LOC in mi-interp.c, but that one makes sense.
gdb/
2013-08-30 Pedro Alves <palves@redhat.com>
* mi/mi-main.c (mi_cmd_trace_find): Use LOC_AND_ADDRESS instead of
SRC_AND_LOC.
I noticed SRC_LINE has special handling within print_stack_frame (mid
statement handling), so I audited all uses, and noticed the one in
restore_selected_frame. I actually added this warning myself back in
2008, but reading back, I think we can do better. "reparsed frame" is
probably confusing to users.
Old:
warning: Couldn't restore frame #2 in current thread, at reparsed frame #0
45 w = 0;
(gdb)
New:
warning: Couldn't restore frame #2 in current thread. Bottom (innermost) frame selected:
#0 foo () at foo.c:45
45 w = 0;
(gdb)
Tested on x86_64 Fedora 17.
gdb/
2013-08-30 Pedro Alves <palves@redhat.com>
* thread.c (restore_selected_frame): Use SRC_AND_LOC, and change
warning text.
1 is SRC_AND_LOC.
Then, this is passing -1 as print_level argument to print_stack_frame.
-1 is not a valid print_level value (it's a regular boolean). But, it
used to be, before
<https://sourceware.org/ml/gdb-patches/2004-04/msg00585.html>.
What happened is that bsd-kvm.c did not exist at the time of that
patch, but went into the tree about a month after, without being
adjusted to the new interface.
Fixed now, exactly as e.g., ocd.c had been adjusted:
> --- ocd.c 18 Jan 2004 19:26:51 -0000 1.28
> +++ ocd.c 23 Apr 2004 14:29:12 -0000
> @@ -225,7 +225,7 @@
> flush_cached_frames ();
> registers_changed ();
> stop_pc = read_pc ();
> - print_stack_frame (get_selected_frame (), -1, 1);
> + print_stack_frame (get_selected_frame (), 0, SRC_AND_LOC);
gdb/
2013-08-30 Pedro Alves <palves@redhat.com>
* bsd-kvm.c (bsd_kvm_open, bsd_kvm_proc_cmd, bsd_kvm_pcb_cmd):
Adjust arguments to print_stack_frame.
This is declaring a function that no longer exists. It was deleted
back in 2003-01-13:
...
show_and_print_stack_frame, print_only_stack_frame_stub,
print_only_stack_frame): Delete functions.
gdb/
2013-08-30 Pedro Alves <palves@redhat.com>
* frame.h (show_and_print_stack_frame): Delete declaration.
Thread support got broken when adding 64bit support on ppc-aix.
Upon digging further, I found that the following patch...
| * gdb_ptrace.h: Use ptrace64 instead of ptrace if HAVE_PTRACE64
| is defined.
| * rs6000-nat.c: Check for __ld_info64_ if compiling 64 BIT gdb.
| (rs6000_ptrace32): Call ptrace64 instead of ptrace if present.
| (rs6000_ptrace64): Call ptace64 instead of ptracex if present.
| * configure.ac: Check for ptrace64.
| * configure, config.in: Regenerate.
... is responsible for this regression:
(gdb) x /x &__n_pthreads
0xf06a8258 <__n_pthreads>: Cannot access memory at address 0xf06a8258
Prior to the patch, we have:
(gdb) x /x &__n_pthreads
0xf06a8258 <__n_pthreads>: 0x00000003
The problem occurs inside rs6000_ptrace32, while calling ptrace64.
The address is given to rs6000_ptrace32 as an "int *", while
ptrace64 takes a "long long". The cast causes the address to be
sign-extended, which results in GDB trying to read the wrong address.
This patch fixes the issue by casting the address to a "uintptr_t"
instead, and letting the compiler do the implicit conversion to
"long long" in the function call.
gdb/ChangeLog:
* rs6000-nat.c (rs6000_ptrace32): Cast "addr" to "uintptr_t"
instead of "long long" in call to ptrace64.
https://sourceware.org/ml/gdb-patches/2013-08/msg00605.html
gdb/ChangeLog
* mi/mi-interp.c (mi_command_loop): Change signature to match
interp_command_loop_ftype.
(mi1_command_loop): Remove.
(mi2_command_loop): Remove.
(mi3_command_loop): Remove.
(mi_interpreter_resume): Remove setting of
deprecated_command_loop_hook.
(_initialize_mi_interp): Set mi_command_loop as the command loop
callback.
I came across a pattern used to construct a value in the following way:
struct value *val = allocate_value_lazy (type);
VALUE_LVAL (val) = lval_memory;
set_value_address (val, address);
Instead we fold the above call into:
value_at_lazy (type, addr);
2013-08-27 Sanimir Agovic <sanimir.agovic@intel.com>
* dwarf2loc.c (dwarf2_evaluate_loc_desc_full): Use value_at_lazy instead
of assembling value via allocate_value_lazy and attribute setter.
* findvar.c (default_read_var_value): Use value_at_lazy instead of
assembling value via allocate_value_lazy and attribute setter.
* valops.c (do_search_struct_field): Use value_at_lazy instead of
assembling value via allocate_value_lazy and attribute setter.
