This new test fails on i686 buildbot slaves,
(gdb) core-file /home/gdb-buildbot-2/fedora-x86-64-2/fedora-i686/build/gdb/testsuite/gdb.arch/i386-biarch-core.core
"/home/gdb-buildbot-2/fedora-x86-64-2/fedora-i686/build/gdb/testsuite/gdb.arch/i386-biarch-core.core"
is not a core dump: File format not recognized
(gdb) FAIL: gdb.arch/i386-biarch-core.exp: core-file
There are two problems:
(1) The testcase did not really test if elf64-i386 is supported by GDB (BFD).
That was OK for a Fedora testcase but I forgot about it when submitting it
upstream.
I haven't really verified if the GNU target is elf64-little but it seems so,
no other one seems suitable from:
elf32-x86-64
elf64-big
elf64-k1om
elf64-l1om
elf64-little
elf64-x86-64
pei-x86-64
(2) The output of the "core-file" command itself can be arbitrary as the
elf64-i386 file with x86_64 registers is really broken; but that does not
matter much, important is the following test whether core file memory is
readable.
./configure --enable-64-bit-bfd
(gdb) core-file /home/jkratoch/redhat/gdb-test-build32-plus64/gdb/testsuite/gdb.arch/i386-biarch-core.core^M
warning: Couldn't find general-purpose registers in core file.^M
Failed to read a valid object file image from memory.^M
warning: Couldn't find general-purpose registers in core file.^M
#0 <unavailable> in ?? ()^M
(gdb) FAIL: gdb.arch/i386-biarch-core.exp: core-file
x/i 0x400078^M
0x400078: hlt ^M
(gdb) PASS: gdb.arch/i386-biarch-core.exp: .text is readable
I do not know much dejagnu but I expect 'istarget' tests against the site.exp
'target_triplet' content which is set to the primary GDB target
(--target=...).
GDB is normally never configured for primary target elf64-i386, I think BFD
does not know such explicit target, it gets recognized as elf64-little.
In fact many testfiles of the GDB testsuite are wrong as they require
'istarget' (therefore primary GDB target) even for just loading arch specific
files which would be sufficient with secondary target (--enable-targets=...)
support.
This my new patch removes this 'istarget' check as it is IMO unrelated to what
we need to test. Although you are right we do 'x/i' and test for 'hlt' so
I think we should test also for available 'set architecture i386'.
We could also test by 'x/bx' instead of 'x/i' to avoid such additional
test/requirement.
This testcase comes from a different bug from 2009:
https://bugzilla.redhat.com/show_bug.cgi?id=457187http://pkgs.fedoraproject.org/cgit/gdb.git/commit/?id=94cd124608bf0dd359cb48a710800d72c21b30c3
That bug has been fixed in the meantime but the same testcase was reproducing
this new different bug - internal error regression - so I submitted it.
We can remove the "x/bx $address" test but it was useful for the previous bug
from 2009 as that time the internal error regression did not happen, just the
core file was not recognized (which would not be detected by the proposed
ignoring of the "core-file" command output) and so the core file was not
available. That can be tested by the "x/bx $address" test.
gdb/testsuite/ChangeLog
2015-07-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/i386-biarch-core.exp: Replace istarget
by "complete set gnutarget". Remove expectation for the "core-file"
command.
New testcase.
gdb/testsuite/ChangeLog
2015-07-15 Aleksandar Ristovski <aristovski@qnx.com
Tests for validate symbol file using build-id.
* gdb.base/solib-mismatch-lib.c: New file.
* gdb.base/solib-mismatch-libmod.c: New file.
* gdb.base/solib-mismatch.c: New file.
* gdb.base/solib-mismatch.exp: New file.
Tracepoints and range stepping are independent features. This patch
skips the gdb.trace/range-stepping.exp test case if the target does not
support range stepping.
gdb/testsuite/ChangeLog:
* gdb.base/range-stepping.exp (gdb_range_stepping_enabled):
Move it to ...
* lib/range-stepping-support.exp (gdb_range_stepping_enabled):
... here.
* gdb.trace/range-stepping.exp: Check that the target supports
range stepping.
This exercises the case of the inferior disappearing while GDB is
debugging it, such as something doing "kill -9 PID" while the program
is stopped under GDB or GDBserver. This triggered a set of internal
errors, fixed by previous patches.
gdb/testsuite/ChangeLog:
2015-07-14 Pedro Alves <palves@redhat.com>
* gdb.base/killed-outside.exp: New file.
* gdb.base/killed-outside.c: New file.
I have somehow missed gdb.asm/asm-source.exp PASS->FAIL even on x86_64.
It has no longer valid assumption that "break" breaks after the prologue even
in assembler. So I have changed this assumption of the testfile.
gdb/testsuite/ChangeLog
2015-07-10 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.asm/asm-source.exp (f at main): Stop at gdbasm_enter.
(n at main): New.
* gdb.asm/asmsrc1.s: Add comment "mark: main enter".
Since the new KFAILs/KPASSs for the infcall tests on x86 and x86_64
targets generated unnecessary noise, this change skips them with
UNSUPPORTED instead.
gdb/testsuite/ChangeLog:
* gdb.base/gnu_vector.exp: On x86 and x86_64 targets, skip the
infcall tests instead of setting up for KFAIL.
When navigating in the recorded execution trace via "record goto", we do not
set stop_pc. This may trigger an internal error in infrun.c when stepping
from that location. Set it.
(gdb) rec full
(gdb) c
Continuing.
Breakpoint 1, foo (void) at foo.c:42
42 x = y
(gdb) rn
foo (void)
at foo.c:41
41 y = x
(gdb) rec go end
Go forward to insn number 98724
at foo.c:42
42 x = y
(gdb) n
infrun.c:2382: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This happens because there's a breakpoint at PC when the "next"
is issued, so that breapoint should be immediately stepped over.
That should have been detected/done by proceed, here:
if (addr == (CORE_ADDR) -1)
{
if (pc == stop_pc
&& breakpoint_here_p (aspace, pc) == ordinary_breakpoint_here
&& execution_direction != EXEC_REVERSE)
/* There is a breakpoint at the address we will resume at,
step one instruction before inserting breakpoints so that
we do not stop right away (and report a second hit at this
breakpoint).
Note, we don't do this in reverse, because we won't
actually be executing the breakpoint insn anyway.
We'll be (un-)executing the previous instruction. */
tp->stepping_over_breakpoint = 1;
But since stop_pc was stale, the pc == stop_pc check failed, and left the
breakpont at PC inserted.
gdb/
* record-btrace.c (record_btrace_goto_begin, record_btrace_goto_end)
record_btrace_goto): Move call to print_stack_frame ...
(record_btrace_set_replay): ... here. Set stop_pc.
* record-full.c (record_full_goto_entry): Set stop_pc.
testsuite/
* gdb.btrace/record_goto-step.exp: New.
GDB could:
compile code struct_object.selffield = &struct_object
./compile/compile-c-types.c:83: internal-error: insert_type: Assertion `add == NULL || add->gcc_type == gcc_type' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.compile/compile.exp: compile code struct_object.selffield = &struct_object (GDB internal
error)
The bug was not in GDB but in the GCC part interfacing with GDB.
Alexandre Oliva has fixed it the right way:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commitdiff;h=072dfdba0ea62abb65514cb3a90cdf3868efe286
git://gcc.gnu.org/git/gcc.git
aoliva/libcp1
Attaching this GDB testsuite update + info to user s/he should upgrade GCC.
After Alex upstreams the fix I can update the message to contain the specific
GCC release.
gdb/ChangeLog
2015-07-08 Jan Kratochvil <jan.kratochvil@redhat.com>
PR compile/18484
* compile/compile-c-types.c (insert_type): Change gdb_assert to error.
gdb/testsuite/ChangeLog
2015-07-08 Jan Kratochvil <jan.kratochvil@redhat.com>
PR compile/18484
* gdb.compile/compile.c (struct struct_type): Add volatile to
selffield's type.
* gdb.compile/compile.exp
(compile code struct_object.selffield = &struct_object): Skip further
struct_object tests if this one xfails.
The existing code preserves 'from' bits, which is incorrect. E.g.
(gdb) maint agent-eval (char)255L
Scope: 0x4008d6
Reg mask: 00
0 const16 255
3 ext 64
5 end
'ext 64' should be 'ext 8'; this bytecode evaluates to 255 instead of
the correct result of -1. The fix is simple. I ran the entire test
suite on x86-64 and there were no new test failures.
gdb/ChangeLog:
2015-07-08 Robert O'Callahan <robert@ocallahan.org>
PR exp/18617
* ax-gdb.c (gen_conversion): Extend to 'to' bits, not 'from'.
gdb/testsuite/ChangeLog:
2015-07-08 Robert O'Callahan <robert@ocallahan.org>
PR exp/18617
* gdb.trace/ax.exp: Add test.
Some tests expect the the target is aarch64, but checking target
triplet is not accurate, because target triplet can be aarch64 but
the program is in arm (or aarch32) state.
This patch addes a new proc is_aarch64_target which returns true
if the target is on aarch64 state.
gdb/testsuite:
2015-07-07 Yao Qi <yao.qi@linaro.org>
* gdb.arch/aarch64-atomic-inst.exp: Check is_aarch64_target
instead of istarget "aarch64*-*-*".
* gdb.arch/aarch64-fp.exp: Likewise.
* gdb.base/float.exp: Likewise.
* gdb.reverse/aarch64.exp: Likewise.
* lib/gdb.exp (is_aarch64_target): New proc.
GDB tests running on arm target should be also run on aarch32
(32-bit mode on aarch64). There should be no difference. It is not
precise to check target triplet to decide which tests should be run,
because if I compiler all the test binary in 32-bit (arm program),
but target triplet is still aarch64, so that these arm specific tests
are skipped.
This patch is to add a new proc is_aarch32_target which return true
if target triplet is arm or the test binary is compiled for arm.
gdb/testsuite:
2015-07-07 Yao Qi <yao.qi@linaro.org>
* lib/gdb.exp (is_aarch32_target): New proc.
* gdb.arch/arm-bl-branch-dest.exp: Check is_aarch32_target
instead of "istarget "arm*-*-*"".
* gdb.arch/arm-disp-step.exp: Likewise.
* gdb.arch/thumb-bx-pc.exp: Likewise.
* gdb.arch/thumb-prologue.exp: Likewise.
* gdb.arch/thumb-singlestep.exp: Likewise.
* gdb.base/disp-step-syscall.exp: Likewise.
* gdb.base/float.exp: Likewise.
This patch is to enable test_catch_syscall_multi_arch on aarch64.
gdb/testsuite:
2015-07-07 Yao Qi <yao.qi@linaro.org>
* gdb.base/catch-syscall.exp (test_catch_syscall_multi_arch):
Set arch1, arch2, syscall1_name, syscall2_name and syscall_number.
Multi-arch related tests under gdb.multi are to compile programs with
the same compiler but different compiler options (-m64 vs -m32). However,
different compilers are needed to compile both aarch64 program and
arm (aarch32) program. This patch is to adjust these test cases to
compile programs in different modes with different compiler.
When we use gcc for arm-linux target, its file name can be different,
arm-linux-gnueabihf-gcc, arm-linux-gnueabi-gcc, or arm-none-linux-gnueabi-gcc,
so I add a variable ARM_CC_FOR_TARGET, so that user can set the name
of gcc for arm-linux target on aarch64, like:
$ make check RUNTESTFLAGS='ARM_CC_FOR_TARGET=arm-linux-gnueabihf-gcc multi-arch.exp'
gdb/testsuite:
2015-07-07 Yao Qi <yao.qi@linaro.org>
* gdb.multi/multi-arch-exec.exp: Set march1 and march2 to "" if target
is aarch64. If target is aarch64, set compiler=${ARM_CC_FOR_TARGET}
if it exists.
* gdb.multi/multi-arch.exp: Likewise.
Patch "Do not skip prologue for asm (.S) files" [1] changes GDB's
behaviour on which test gdb.arch/thumb-singlestep.exp depends, so
it causes the fail below:
(gdb) si^M
37 blx foo^M
(gdb) FAIL: gdb.arch/thumb-singlestep.exp: step into foo
the test assumes the program will stop at the instruction after "push"
but it doesn't. The fix to this fail is to do one more single step.
[1] https://sourceware.org/ml/gdb-patches/2015-06/msg00561.html
gdb/testsuite:
2015-07-07 Yao Qi <yao.qi@linaro.org>
* gdb.arch/thumb-singlestep.exp: Do one more single step.
As these characters don't need to be escaped for strings
wrapped inside {} braces, we can remove the unneeded backslashes.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (test_class_help): Remove the unneeded escaping of
'[' and ']' characters.
Refs:
https://sourceware.org/ml/gdb/2015-03/msg00024.htmlhttps://sourceware.org/ml/gdb/2015-06/msg00005.html
On GNU/Linux, if an infcall spawns a thread, that thread ends up with
stuck running state. This happens because:
- when linux-nat.c detects a new thread, it marks them as running,
and does not report anything to the core.
- we skip finish_thread_state when the thread that is running the
infcall stops.
As result, that new thread ends up with stuck "running" state, even
though it really is stopped.
On Windows, _all_ threads end up stuck in running state, not just the
one that was spawned. That happens because when a new thread is
detected, unlike linux-nat.c, windows-nat.c reports
TARGET_WAITKIND_SPURIOUS to infrun. It's the fact that that event
does not cause a user-visible stop that triggers the problem. When
the target is re-resumed, we call set_running with a wildcard ptid,
which marks all thread as running. That set_running is not suppressed
because the (leader) thread being resumed does not have in_infcall
set. Later, when the infcall finally finishes successfully, nothing
marks all threads back to stopped.
We can trigger the same problem on all targets by having a thread
other than the one that is running the infcall report a breakpoint hit
to infrun, and then have that breakpoint not cause a stop. That's
what the included test does.
The fix is to stop GDB from suppressing the set_running calls while
doing an infcall, and then set the threads back to stopped when the
call finishes, iff they were originally stopped before the infcall
started. (Note the MI *running/*stopped event suppression isn't
affected.)
Tested on x86_64 GNU/Linux.
gdb/ChangeLog:
2015-06-29 Pedro Alves <palves@redhat.com>
PR threads/18127
* infcall.c (run_inferior_call): On infcall success, if the thread
was marked stopped before, reset it back to stopped.
* infrun.c (resume): Don't suppress the set_running calls when
doing an infcall.
(normal_stop): Only discard the finish_thread_state cleanup if the
infcall succeeded.
gdb/testsuite/ChangeLog:
2015-06-29 Pedro Alves <palves@redhat.com>
PR threads/18127
* gdb.threads/hand-call-new-thread.c: New file.
* gdb.threads/hand-call-new-thread.c: New file.
Last year a patch was submitted/approved/commited to eliminate
symbol_matches_domain which was causing this problem. It was later reverted
because it introduced a (severe) performance regression.
Recap:
(gdb) list
1 enum e {A,B,C} e;
2 int main (void) { return 0; }
3
(gdb) p e
Attempt to use a type name as an expression
The parser attempts to find a symbol named "e" of VAR_DOMAIN.
This gets passed down through lookup_symbol and (eventually) into
block_lookup_symbol_primary, which iterates over the block's dictionary
of symbols:
for (sym = dict_iter_name_first (block->dict, name, &dict_iter);
sym != NULL;
sym = dict_iter_name_next (name, &dict_iter))
{
if (symbol_matches_domain (SYMBOL_LANGUAGE (sym),
SYMBOL_DOMAIN (sym), domain))
return sym;
}
The problem here is that we have a symbol named "e" in both STRUCT_DOMAIN
and VAR_DOMAIN, and for languages like C++, Java, and Ada, where a tag name
may be used as an implicit typedef of the type, symbol_matches_domain ignores
the difference between VAR_DOMAIN and STRUCT_DOMAIN. As it happens, the
STRUCT_DOMAIN symbol is found first, considered a match, and that symbol is
returned to the parser, eliciting the (now dreaded) error message.
Since this bug exists specifically because we have both STRUCT and VAR_DOMAIN
symbols in a given block/CU, this patch rather simply/naively changes
block_lookup_symbol_primary so that it continues to search for an exact
domain match on the symbol if symbol_matches_domain returns a symbol
which does not exactly match the requested domain.
This "fixes" the immediate problem, but admittedly might uncover other,
related bugs. [Paranoia?] However, it causes no regressions (functional
or performance) in the test suite. A similar change has been made
to block_lookup_symbol for other cases in which this bug might appear.
The tests from the previous submission have been resurrected and updated.
However since we can still be given a matching symbol with a different domain
than requested, we cannot say that a symbol "was not found." The error
messages today will still be the (dreaded) "Attempt to use a type name..."
ChangeLog
PR 16253
* block.c (block_lookup_symbol): For non-function blocks,
continue to search for a symbol with an exact domain match
Otherwise, return any previously found "best domain" symbol.
(block_lookup_symbol_primary): Likewise.
testsuite/ChangeLog
PR 16253
* gdb.cp/var-tag-2.cc: New file.
* gdb.cp/var-tag-3.cc: New file.
* gdb.cp/var-tag-4.cc: New file.
* gdb.cp/var-tag.cc: New file.
* gdb.cp/var-tag.exp: New file.
This patch implements the new option "history remove-duplicates", which
controls the removal of duplicate history entries ("off" by default).
The motivation for this option is to be able to reduce the prevalence of
basic commands such as "up" and "down" in the history file. These
common commands crowd out more unique commands in the history file (when
the history file has a fixed size), and they make navigation of the
history file via ^P, ^N and ^R more inconvenient.
The option takes an integer denoting the number of history entries to
look back at for a history entry that is a duplicate of the latest one.
"history remove-duplicates 1" is equivalent to bash's ignoredups option,
and "history remove-duplicates unlimited" is equivalent to bash's
erasedups option.
[ I decided to go with this integer approach instead of a tri-state enum
because it's slightly more flexible and seemingly more intuitive than
leave/erase/ignore. ]
gdb/ChangeLog:
* NEWS: Mention the new option "history remove-duplicates".
* top.c (history_remove_duplicates): New static variable.
(show_history_remove_duplicates): New static function.
(gdb_add_history): Conditionally remove duplicate history
entries.
(init_main): Add "history remove-duplicates" option.
gdb/doc/ChangeLog:
* gdb.texinfo (Command History): Document the new option
"history remove-duplicates".
gdb/testsuite/ChangeLog:
* gdb.base/history-duplicates.exp: New test.
The implementation is pretty straightforward, with the only caveat being
that the "src", "cmd", "next" and "prev" entries get delibrately added
to the completion list even when the TUI has not yet been initialized
(i.e. has never been enabled during the session), since invoking the
"focus" command with these arguments already works when the TUI has not
yet been initialized.
gdb/ChangeLog:
* tui/tui-win.c (focus_completer): New static function.
(_initialize_tui_win): Set the completion function of the
"focus" command to focus_completer.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Test the completion of the "focus"
command.
GDB tries to skip prologue for .S files according to .debug_line but it then
places the breakpoint to a location where it is never hit.
This is because #defines in .S files cause prologue skipping which is
completely inappropriate, for s390x:
glibc/sysdeps/unix/syscall-template.S
78:/* This is a "normal" system call stub: if there is an error,
79: it returns -1 and sets errno. */
80:
81:T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
82: ret
00000000000f4210 T __select
Line Number Statements:
Extended opcode 2: set Address to 0xf41c8
Advance Line by 80 to 81
Copy
Advance PC by 102 to 0xf422e
Special opcode 6: advance Address by 0 to 0xf422e and Line by 1 to 82
Special opcode 34: advance Address by 2 to 0xf4230 and Line by 1 to 83
Advance PC by 38 to 0xf4256
Extended opcode 1: End of Sequence
Compilation Unit @ offset 0x28b3e0:
<0><28b3eb>: Abbrev Number: 1 (DW_TAG_compile_unit)
<28b3ec> DW_AT_stmt_list : 0x7b439
<28b3f0> DW_AT_low_pc : 0xf41c8
<28b3f8> DW_AT_high_pc : 0xf4256
<28b400> DW_AT_name : ../sysdeps/unix/syscall-template.S
<28b423> DW_AT_comp_dir : /usr/src/debug////////glibc-2.17-c758a686/misc
<28b452> DW_AT_producer : GNU AS 2.23.52.0.1
<28b465> DW_AT_language : 32769 (MIPS assembler)
without debuginfo or with debuginfo and the fix - correct address:
(gdb) b select
Breakpoint 1 at 0xf4210
It is also where .dynsym+.symtab point to:
00000000000f4210 T __select
00000000000f4210 W select
with debuginfo, without the fix:
(gdb) b select
Breakpoint 1 at 0xf41c8: file ../sysdeps/unix/syscall-template.S, line 81.
One part is to behave for asm files similar way like for 'locations_valid':
/* Symtab has been compiled with both optimizations and debug info so that
GDB may stop skipping prologues as variables locations are valid already
at function entry points. */
unsigned int locations_valid : 1;
The other part is to extend the 'locations_valid'-like functionality more.
Both minsym_found and find_function_start_sal need to be patched, otherwise
their addresses do not match and GDB regresses on ppc64:
gdb/ChangeLog
2015-06-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* linespec.c (minsym_found): Reset sal.PC for COMPUNIT_LOCATIONS_VALID
and language_asm..
* symtab.c (find_function_start_sal): Likewise.
gdb/testsuite/ChangeLog
2015-06-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/amd64-prologue-skip.S: New file.
* gdb.arch/amd64-prologue-skip.exp: New file.
linux_get_siginfo_type is installed to many linux gdbarch. This patch
is to move this to a common area linux-tdep.c:linux_init_abi, so that
linux_get_siginfo_type is installed to every linux gdbarch. If some
linux gdbarch needs its own version, please override it in
$ARCH_linux_init_abi. In the testsuite, we enable siginfo related
tests for all linux targets.
gdb:
2015-06-24 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-tdep.c (aarch64_linux_init_abi): Don't call
set_gdbarch_get_siginfo_type.
* amd64-linux-tdep.c (amd64_linux_init_abi_common): Likewise.
* arm-linux-tdep.c (arm_linux_init_abi): Likewise.
* i386-linux-tdep.c (i386_linux_init_abi): Likewise.
* m68klinux-tdep.c (m68k_linux_init_abi): Likewise.
* ppc-linux-tdep.c (ppc_linux_init_abi): Likewise.
* s390-linux-tdep.c (s390_gdbarch_init): Likewise.
* tilegx-linux-tdep.c (tilegx_linux_init_abi): Likewise.
* linux-tdep.c (linux_get_siginfo_type): Change it to static.
(linux_init_abi): Call set_gdbarch_get_siginfo_type.
* linux-tdep.h (linux_get_siginfo_type): Remove the declaration.
gdb/testsuite:
2015-06-24 Yao Qi <yao.qi@linaro.org>
* lib/gdb.exp (supports_get_siginfo_type): Return 1 for all
linux targets.
Both siginfo-obj.exp and siginfo-thread.exp have the same code
checking the support of geting a type of siginfo for a given arch.
This patch is to move these code into a proc supports_get_siginfo_type.
gdb/testsuite:
2015-06-24 Yao Qi <yao.qi@linaro.org>
* lib/gdb.exp (supports_get_siginfo_type): New proc.
* gdb.base/siginfo-obj.exp: Invoke supports_get_siginfo_type.
* gdb.base/siginfo-thread.exp: Likewise.
This commit is to add comments on using this board file and the
requirements on localhost.
gdb/testsuite:
2015-06-22 Yao Qi <yao.qi@linaro.org>
* boards/remote-gdbserver-on-localhost.exp: Add comments.
This patch is to let skip_hw_breakpoint_tests and skip_hw_watchpoint_tests
return 0 for aarch64 target, since aarch64 has HW watchpoint and
breakpoint registers.
With this patch applied, about 1560 watchpoint/breakpoint related tests
become enabled on aarch64-linux native testing.
gdb/testsuite:
2015-06-22 Yao Qi <yao.qi@linaro.org>
* lib/gdb.exp (skip_hw_breakpoint_tests): Return 0 for target
aarch64*-*-*.
(skip_hw_watchpoint_tests): Likewise.
The value inside the GDBHISTSIZE environment variable, only if valid,
should override setting the history size through one's .gdbinit file.
gdb/testsuite/ChangeLog:
* gdb.base/gdbinit-history.exp: Test the interaction between
setting GDBHISTSIZE and setting the history size via .gdbinit.
When GDB reads a nonsensical value for the GDBHISTSIZE environment
variable, i.e. one that is non-numeric or negative, GDB then sets its
history size to 0. This behavior is annoying and also inconsistent
with the behavior of bash.
This patch makes the behavior of invalid GDBHISTSIZE consistent with how
bash handles HISTSIZE. When we encounter a null or out-of-range
GDBHISTSIZE (outside of [0, INT_MAX]) we now set the history size to
unlimited instead of 0. When we encounter a non-numeric GDBHISTSIZE we
do nothing.
gdb/ChangeLog:
PR gdb/16999
* NEWS: Mention new GDBHISTSIZE behavior.
* top.c (init_history): For null or out-of-range GDBHISTSIZE,
set history size to unlimited. Ignore non-numeric GDBHISTSIZE.
gdb/doc/ChangeLog:
PR gdb/16999
* gdb.texinfo (Command History): Mention new GDBHISTSIZE
behavior.
gdb/testsuite/ChangeLog:
PR gdb/16999
* gdb.base/gdbhistsize-history.exp: New test.
The HISTSIZE environment variable is generally expected to be read by
shells, not by applications. Some distros for example globally export
HISTSIZE in /etc/profile -- with the intention that it only affects
shells -- and by doing so it renders useless GDB's own mechanism for
setting the history size via .gdbinit. Also, annoyances may arise when
HISTSIZE is not interpreted the same way by the shell and by GDB, e.g.
PR gdb/16999. That can always be fixed on a shell-by-shell basis but it
may be impossible to be consistent with the behavior of all shells at
once. Finally it just makes sense to not confound shell environment
variables with application environment variables.
gdb/ChangeLog:
* NEWS: Mention that GDBHISTSIZE is read instead of HISTSIZE.
* top.c (init_history): Read from GDBHISTSIZE instead of
HISTSIZE.
(init_main): Refer to GDBHISTSIZE instead of HISTSIZE.
gdb/doc/ChangeLog:
* gdb.texinfo (Command History): Replace occurrences of HISTSIZE
with GDBHISTSIZE.
gdb/testsuite/ChangeLog:
* gdb.base/gdbinit-history.exp: Replace occurrences of HISTSIZE
with GDBHISTSIZE.
* gdb.base/readline.exp: Likewise.
This patch fixes the following tcl error
Running ../../../binutils-gdb/gdb/testsuite/gdb.base/break-interp.exp ...
ERROR: (DejaGnu) proc "else" does not exist.
The error code is NONE
The info on the error is:
invalid command name "else"
while executing
"::tcl_unknown else"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::tcl_unknown $args"
gdb/testsuite:
2015-06-17 Yao Qi <yao.qi@linaro.org>
* lib/gdb.exp (get_build_id): Move braces and "else" to the same
line.
We still do not handle "set history size unlimited" correctly. In
particular, after writing to the history file, we truncate the history
even if it is unlimited.
This patch makes sure that we do not call history_truncate_file() if the
history is not stifled (i.e. if it's unlimited). This bug causes the
history file to be truncated to zero on exit when one has "set history
size unlimited" in their gdbinit file. Although this code exists in GDB
7.8, the bug is masked by a pre-existing bug that's been only fixed in
GDB 7.9 (PR gdb/17820).
gdb/ChangeLog:
* top.c (gdb_safe_append_history): Do not call
history_truncate_file if the history is not stifled.
gdb/testsuite/ChangeLog:
* gdb.base/gdbinit-history.exp: Add test case to check that
an unlimited history file does not get truncated on exit.
So far the gnu_vector test was limited to "static" aspects of GDB's
vector support, like evaluating vector-valued expressions. This patch
enriches the test and adds checks for GDB's vector ABI support as well.
The new checks particularly verify inferior function calls with vector
arguments and GDB's handling of vector return values.
The test now attempts to compile for the target's "native" architecture,
such that a hardware vector ABI is used if available.
Since GDB has no vector ABI support for x86 and x86_64 targets, most of
the new checks are KFAILed there.
gdb/testsuite/ChangeLog:
* gdb.base/gnu_vector.c: Include stdarg.h and stdio.h.
(VECTOR): New macro. Use it...
(int4, uint4, char4, float4, int2, longlong2, float2, double2):
...for these typedefs.
(int8, char1, int1, double1): New typedefs.
(struct just_int2, struct two_int2): New structures.
(add_some_intvecs, add_many_charvecs, add_various_floatvecs)
(add_structvecs, add_singlevecs): New functions.
(main): Call add_some_intvecs twice.
* gdb.base/gnu_vector.exp: Drop GCC version check; just attempt
the compile and exit upon failure. Try compiling for the "native"
architecture. Test inferior function calls with vector arguments
and vector return value handling with "finish" and "return".
This promotes BFD's struct elf_build_id to the generic struct bfd_build_id,
populated when an ELF or PE BFD is read.
gdb is updated to use that, and to use the build-id to find symbols for PE files
also.
There is currently no generic way to extract the build-id from an object file,
perhaps an option to objdump to do this might make sense?
On x86_64-pc-cygwin, gdb's sepdebug.exp changes:
-# of unsupported tests 1
+# of expected passes 90
I don't seem to get consistent testsuite runs on i686-linux-gnu, but there
don't appear to be any regressions.
bfd/ChangeLog:
2015-06-10 Jon Turney <jon.turney@dronecode.org.uk>
* elf-bfd.h : Remove struct elf_build_id.
* bfd.c : Add struct bfd_build_id.
* bfd-in2.h: Regenerate.
* elf.c (elfobj_grok_gnu_build_id): Update to use bfd_build_id.
* libpei.h: Add protoype and macros for
bfd_XXi_slurp_codeview_record.
* peXXigen.c (_bfd_XXi_slurp_codeview_record): Make public
* peicode.h (pe_bfd_read_buildid): Add.
(pe_bfd_object_p): Use pe_bfd_read_buildid().
gdb/ChangeLog:
2015-06-10 Jon Turney <jon.turney@dronecode.org.uk>
* build-id.c: Don't include elf-bfd.h.
(build_id_bfd_get): Use bfd_build_id.
(build_id_verify): Ditto.
* build-id.h: Ditto.
(find_separate_debug_file_by_buildid): Ditto.
* python/py-objfile.c: Don't include elf-bfd.h.
(objfpy_get_build_id) Use bfd_build_id.
(objfpy_build_id_matches, objfpy_lookup_objfile_by_build_id): Ditto.
* coffread.c: Include build-id.h.
(coff_symfile_read): Try find_separate_debug_file_by_buildid.
gdb/doc/ChangeLog:
2015-06-10 Jon Turney <jon.turney@dronecode.org.uk>
* gdb.texinfo (Separate Debug Files): Document that PE is also
supported.
gdb/testsuite/ChangeLog:
2015-06-10 Jon Turney <jon.turney@dronecode.org.uk>
* gdb.base/sepdebug.exp: Add EXEEXT where needed.
* lib/gdb.exp (get_build_id): Teach how to extract build-id from a
PE file.
* lib/future.exp (gdb_find_objdump): Add gdb_find_objdump.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
This patch fixes the "Format string required" error when trying to print
a dprintf on a now resolved, pending location when set via the MI interface
even if the format string is entered correctly.
This patch also adds a test case to check that issue called
mi-dprintf-pending.exp.
gdb/ChangeLog:
PR breakpoints/16465
* breakpoint.c (create_breakpoint): Save extra_string for
pending breakpoints.
gdb/testsuite/ChangeLog:
PR breakpoints/16465
* gdb.mi/mi-dprintf-pending.c: New file.
* gdb.mi/mi-dprintf-pending.exp: New test.
* gdb.mi/mi-dprintf-pendshr.c: New file.
Patch implementing '@' GDB array operator in GCC has been rejected:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00414.html
and so there is now a GDB tracker to implement it just in GDB:
https://sourceware.org/bugzilla/show_bug.cgi?id=18489
gdb/testsuite/ChangeLog
2015-06-04 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile-print.exp (compile print *vararray@3)
(compile print *vararrayp@3): Change xfail to kfail compile/18489.
Currently inferior memory is allocated by inferior mmap() but it is never
deallocated; despite the injected objfile incl. its symbols is freed. This was
intentional so that one can do for example:
inferior:
char *str = "foo";
GDB:
(gdb) compile code str = "bar";
I believe later patches will be needed to introduce full control over keeping
vs. discarding the injected module as being discussed in:
compile: objfiles lifetime UI
https://sourceware.org/ml/gdb/2015-04/msg00051.html
Message-ID: <20150429135735.GA16974@host1.jankratochvil.net>
https://sourceware.org/ml/gdb/2015-05/msg00007.html
As decided by Phil it is better not to leak inferior pages as users can
workaround the issue above for example by:
(gdb) compile code str = strdup ("bar");
I have checked that in fact gdb/doc/ (written by Phil) already expects the
injected code will be unmapped so that does not need to be changed:
compile code int ff = 5; p = &ff;
In this example, @code{p} would point to @code{ff} when the
@code{compile} command is executing the source code provided to it.
However, as variables in the (example) program persist with their
assigned values, the variable @code{p} would point to an invalid
location when the command exists.
gdb/ChangeLog
2015-04-28 Jan Kratochvil <jan.kratochvil@redhat.com>
* arch-utils.c (default_infcall_munmap): New.
* arch-utils.h (default_infcall_munmap): New declaration.
* compile/compile-object-load.c (struct munmap_list, munmap_list_add)
(munmap_list_free, munmap_listp_free_cleanup): New.
(struct setup_sections_data): Add field munmap_list_headp.
(setup_sections): Call munmap_list_add.
(compile_object_load): New variable munmap_list_head, initialize
setup_sections_data.munmap_list_headp, return munmap_list_head.
* compile/compile-object-load.h (struct munmap_list): New declaration.
(struct compile_module): Add field munmap_list_head.
(munmap_list_free): New declaration.
* compile/compile-object-run.c (struct do_module_cleanup): Add field
munmap_list_head.
(do_module_cleanup): Call munmap_list_free.
(compile_object_run): Pass munmap_list_head to do_module_cleanup.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (infcall_munmap): New.
* linux-tdep.c (linux_infcall_munmap): New.
(linux_init_abi): Install it.
gdb/testsuite/ChangeLog
2015-04-28 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile.exp (keep jit in memory): Rename to ...
(do not keep jit in memory): ... this.
(expect 5): Change it to ...
(expect no 5): ... this.
I sent a patch in 2013 for this (incorrectly named =thread-created):
https://cygwin.com/ml/gdb-patches/2013-06/msg00129.html
Tom Tromey was ok with the change, but suggested to add a test as well.
Then I forgot about this patch until today. So here it is again, with the
corresponding test.
The problem is that the =thread-exited event does not appear when detaching
from a local process. It does appear with remote though. It's not a really
big deal, but I'd like it to be consistent.
Tested with local and remote Linux on my Ubuntu 14.04.
gdb/ChangeLog:
PR gdb/15564
* inferior.c (detach_inferior): Call exit_inferior_1 with silent = 0.
gdb/testsuite/ChangeLog:
PR gdb/15564
* gdb.mi/mi-detach.exp: New file.
Initially there is some chain (let's say the longest one
but that doe snot matter). Consequently its elements from the middle are
being removed and there remains only some few unambiguous top and bottom ones.
The original idea why the comparison should be sharp ("<") was that if there
are multiple chains like (0xaddr show jmp instruction address):
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x200) -> c(0x300) -> d(0x400)
then - such situation cannot exist - if two jmp instructions in "a" have the
same address they must also jump to the same address (*).
(*) jump to a computed address would be never considered for the DWARF
tail-call records.
So there could be:
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x270) -> c(0x300) -> d(0x400)
But then "a" frame itself is ambiguous and it must not be displayed.
I did not realize that there can be self-tail-call:
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x280) -> a(0x200) -> d(0x400)
which intersects to:
main(0x100) -> <???>? -> a(0x200) -> d(0x400)
And so if the first chain was chosen the
main(0x100) -> a(0x200) -> d(0x400)
then the final intersection has callers+callees==length.
> for example, if CALLERS is 3 and
> CALLEES is 2, what does the chain look like?
main(0x100) -> x(0x150) -> y(0x200) -> <???>? -> a(0x200) -> d(0x400)
And if LENGTH is 7 then:
call_site[0] = main(0x100)
call_site[1] = x(0x150)
call_site[2] = y(0x200)
call_site[3] = garbage
call_site[4] = garbage
call_site[5] = a(0x200)
call_site[6] = d(0x400)
gdb/ChangeLog
2015-06-01 Andreas Schwab <schwab@linux-m68k.org>
Jan Kratochvil <jan.kratochvil@redhat.com>
PR symtab/18392
* dwarf2-frame-tailcall.c (pretended_chain_levels): Correct
assertion.
* dwarf2loc.c (chain_candidate): Likewise.
gdb/testsuite/ChangeLog
2015-06-01 Jan Kratochvil <jan.kratochvil@redhat.com>
PR symtab/18392
* gdb.arch/amd64-tailcall-self.S: New file.
* gdb.arch/amd64-tailcall-self.c: New file.
* gdb.arch/amd64-tailcall-self.exp: New file.
The native-extended-gdbserver target now supports fork events and
follow fork, but it does not yet support exec events. Some of the
tests in gdb.base/foll-vfork.exp depend on exec events. This patch
disables those tests for remote targets. We can re-enable these
once the exec event support goes in.
gdb/testsuite/
* gdb.base/foll-vfork.exp (main): Disable exec-dependent
tests for remote targets by checking is_target_gdbserver.
gdb/ChangeLog:
* cp-support.c (cp_lookup_rtti_type): Handle the case of NAME being
a typedef.
gdb/testsuite/ChangeLog:
* gdb.cp/iostream.cc: New file.
* gdb.cp/iostream.exp: New file.
This patch adds a test case to test the process record for some of
aarch64 instructions.
In each function, GDB turns on process record, and single step until
program goes to the end of the function. Then, single step backward.
In each of forward single step and backward single step, the contents
of registers are saved, and test compares them. If there is any
differences, a FAIL is emitted.
The test is flexible, and we can test other instructions easily in the
future.
gdb/testsuite:
2015-05-26 Omair Javaid <omair.javaid@linaro.org>
Yao Qi <yao.qi@linaro.org>
* gdb.reverse/aarch64.c: New.
* gdb.reverse/aarch64.exp: New.
