This commit renames nine files that contain code used by both 32- and
64-bit Intel ports such that their names are prefixed with "x86"
rather than "i386". All types, functions and variables within these
files are likewise renamed such that their names are prefixed with
"x86" rather than "i386". This makes GDB follow the convention used
by gdbserver such that 32-bit Intel code lives in files called
"i386-*", 64-bit Intel code lives in files called "amd64-*", and code
for both 32- and 64-bit Intel lives in files called "x86-*".
This commit only renames OS-independent files. The Linux ports of
both GDB and gdbserver now follow the i386/amd64/x86 convention fully.
Some ports still use the old convention where "i386" in file/function/
type/variable names can mean "32-bit only" or "32- and 64-bit" but I
don't want to touch ports I can't fully test except where absolutely
necessary.
gdb/ChangeLog:
* i386-nat.h: Renamed as...
* x86-nat.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* i386-nat.c: Renamed as...
* x86-nat.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* common/i386-xstate.h: Renamed as...
* common/x86-xstate.h: New file. All type, function and variable
name prefixes changed from "i386_" to "x86_". All references
updated.
* nat/i386-cpuid.h: Renamed as...
* nat/x86-cpuid.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* nat/i386-gcc-cpuid.h: Renamed as...
* nat/x86-gcc-cpuid.h: New file. All type, function and variable
name prefixes changed from "i386_" to "x86_". All references
updated.
* nat/i386-dregs.h: Renamed as...
* nat/x86-dregs.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* nat/i386-dregs.c: Renamed as...
* nat/x86-dregs.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
gdb/gdbserver/ChangeLog:
* i386-low.h: Renamed as...
* x86-low.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* i386-low.c: Renamed as...
* x86-low.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
This commit replaces two uses of xcalloc (1, ...) with XCNEW.
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (x86_linux_new_process): Use XCNEW.
(x86_linux_new_thread): Likewise.
This commit replaces the hacky "exception" system in gdbserver with
the exceptions and cleanups subsystem from GDB.
Only the catch/cleanup code in what was "main" has been updated to
use the new system. Other parts of gdbserver can now be converted
to use TRY_CATCH and cleanups on an as-needed basis.
A side-effect of this commit is that some error messages will change
slightly, and in cases with multiple errors the error messages will
be printed in a different order.
gdb/gdbserver/ChangeLog:
* server.h (setjmp.h): Do not include.
(toplevel): Do not declare.
(common-exceptions.h): Include.
(cleanups.h): Likewise.
* server.c (toplevel): Do not define.
(exit_code): New static global.
(detach_or_kill_for_exit_cleanup): New function.
(main): New function. Original main renamed to...
(captured_main): New function.
* utils.c (verror) [!IN_PROCESS_AGENT]: Use throw_verror.
This commit creates a new file, common/gdb_setjmp.h, to hold some
portability macros for setjmp/longjmp et al. that are used by the
exceptions subsystem and by the demangler crash catcher.
gdb/ChangeLog:
* common/gdb_setjmp.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add common/gdb_setjmp.h.
* configure.ac: Move sigsetjmp check...
* common/common.m4: ...here.
* configure: Regenerate.
* cp-support.c (SIGJMP_BUF): Delete.
(SIGSETJMP): Likewise.
(SIGLONGJMP): Likewise.
* exceptions.h (gdb_setjmp.h): Include.
(setjmp.h): Do not include.
(EXCEPTIONS_SIGJMP_BUF): Delete.
(EXCEPTIONS_SIGSETJMP): Likewise.
(EXCEPTIONS_SIGLONGJMP): Likewise.
Replace all uses of EXCEPTIONS_SIG* macros with SIG* macros
from gdb_setjmp.h.
* exceptions.c: Likewise.
gdb/gdbserver/ChangeLog:
* config.in: Regenerate.
* configure: Likewise.
This commit moves cleanups.[ch] into gdb/common/. The only change to
the content of the files is that cleanups.c's include list was altered
to match its new location.
gdb/ChangeLog:
* cleanups.h: Moved to...
* common/cleanups.h: New file.
* cleanups.c: Moved to...
* common/cleanups.c: New file. Include common-defs.h and
cleanups.h. Do not include defs.h.
* Makefile.in (SFILES): Replace cleanups.c with common/cleanups.c.
(HFILES_NO_SRCDIR): Replace cleanups.h with common/cleanups.h.
(cleanups.o): New rule.
gdb/gdbserver/ChangeLog:
* Makefile.in (SFILES): Add common/cleanups.c.
(OBS): cleanups.o.
(cleanups.o): New rule.
Various warnings are emitted during startup and option-parsing using
fprintf_unfiltered. One warning is prefixed with the command name,
the others are not. This commit replaces these hardwired warnings
with calls to warning. It also sets warning_pre_print to prefix all
warnings with the command name until option parsing is complete.
gdb/ChangeLog:
* main.c (captured_main): Use warning during startup.
Prefix startup warning messages with command name.
This commit replaces the hardwired fprintf/exit error handlers
for usage errors with calls to error.
gdb/ChangeLog:
* main.c (captured_main): Handle usage errors with error.
go32_create_inferior invokes a hardwired fprintf/exit error handler
if v2loadimage fails. I could find no reason for this other than that
the block seems to have been copy-and-pasted from v2loadimage's
manpage. This commit replaces the hardwired handler with a call to
error.
gdb/ChangeLog:
* go32-nat.c (go32_create_inferior): Replace a fprintf/
exit pair with a call to error. Wrap the message with _().
If the requested interpreter cannot be set captured_main reports the
error with a hardwired fprintf/exit pair. A fprintf/exit pair on the
previous line was replaced with a call to error in March 2003
(https://sourceware.org/ml/gdb-patches/2003-03/msg00444.html) but I
found no documentation as to why this particular hardwired handler
was left untouched. I was also unable to come up with a situation
where error would not be suitable, so I have replaced it with a call
to error.
gdb/ChangeLog:
* main.c (captured_main): Replace a fprintf/exit
pair with a call to error. Wrap the message with _().
tui_initialize_io contains a pair of hardwired fprintf/exit error
handlers. I was unable to find any documentation as to why they're
hardwired (the code appeared in a monolithic block back in 2001:
https://sourceware.org/ml/gdb-patches/2001-07/msg00490.html) and I
was also unable to come up with a situation where error would not
be suitable, so I have replaced both handlers with calls to error.
gdb/ChangeLog:
* tui/tui-io.c (tui_initialize_io): Replace two fprintf/exit
pairs with calls to error. Wrap the message with _().
warning will crash if called before the first call to set_width. This
commit makes the warning usable from the moment gdb_stderr is set up.
gdb/ChangeLog:
* utils.c (vwarning): Protect calls to target_terminal_ours
and wrap_here.
error (and other exception-throwing functions) are callable from the
first line of captured_main, but the exception printing code will
crash if called before the first call to set_width. This commit makes
the exception printing code usable from the moment gdb_stderr is set
up.
gdb/ChangeLog:
* exceptions.c (print_flush): Protect calls to
target_terminal_ours and wrap_here.
internal_vproblem can be called (via malloc_failure) from almost the
first line of captured_main, but it will crash if called before the
first call to set_width. This commit makes internal_vproblem work
at any time.
There are two parts to this. If called before gdb_stderr is set up,
internal_vproblem will fall back to printing the message on regular
stderr and aborting. If called after gdb_stderr is set up but before
filtered printing is set up, internal_vproblem will operate as usual
except that it can not query whether to quit and/or dump core so it
defaults to doing both.
gdb/ChangeLog:
* utils.h (filtered_printing_initialized): New declaration.
* utils.c (abort_with_message): New function.
(internal_vproblem): Use abort_with_message for first level
recursive internal problems, and if gdb_stderr is not set up.
Protect calls to target_terminal_ours, begin_line and query.
clang was using eax to construct %0 here:
asm ("mov %%eax, 0(%0)\n\t"
"mov %%ebx, 4(%0)\n\t"
"mov %%ecx, 8(%0)\n\t"
"mov %%edx, 12(%0)\n\t"
"mov %%esi, 16(%0)\n\t"
"mov %%edi, 20(%0)\n\t"
: /* no output operands */
: "r" (data)
: "eax", "ebx", "ecx", "edx", "esi", "edi");
which caused amd64-word.exp (and others similarly) to fail.
It's a perfectly legit thing for clang to do given the available data.
The patch fixes this by marking the registers as live from the
time of the preceding breakpoint.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-pseudo.c (main): Rewrite to better specify when
eax,etc. are live with values set by gdb and thus the compiler can't
use them.
* gdb.arch/i386-pseudo.c (main): Ditto.
This commit removes the now-unused fatal function and prototype.
gdb/gdbserver/ChangeLog:
* utils.h (fatal): Remove declaration.
* utils.c (fatal): Remove function.
This commit converts four calls to fatal into calls to
perror_with_name. perror_with_name calls error, which
in IPA terminates with exit (1) rather than longjmp, so
there is no functional change here.
gdb/gdbserver/ChangeLog:
* tracepoint.c (gdb_agent_init): Replace fatal with
perror_with_name.
(initialize_tracepoint): Likewise.
This commit converts a call to fatal in remote_prepare with a call to
error. remote_prepare is called precisely once, from main, at a point
where jumping to toplevel will call exit (1), so error and fatal are
functionally equivalent at this point. Note that remote_prepare calls
perror_with_name (which calls error) so callers of remote_prepare must
already handle the fact that it may exit via longjmp.
gdb/gdbserver/ChangeLog:
* remote-utils.c (remote_prepare): Replace fatal with error.
This commit downgrades a fatal error to a warning in linux_async.
linux_async is called from two different places in gdbserver:
Via target_async from handle_accept_event. The argument
is always zero, so the warning will never be printed here.
Via start_non_stop from handle_general_set. This prints
its own error message to stderr on failure, which will
be preceded by the warning if it is emitted.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_async): Replace fatal with warning.
Tidy up and return.
(linux_start_non_stop): Return -1 if linux_async failed.
This commit converts if..fatal checks in both i386_dr_low_set_addr
implementations to gdb_asserts. It's not obvious from the context,
but the conditional in both cases is changed to match the equivalent
conditional in the i386_dr_low_get_addr implementations. Nothing
fundamental has changed because DR_FIRSTADDR is zero. This commit
also removes a vague comment in Linux i386_dr_low_get_addr. I could
have reworded the comment (and replicated it three times for the other
identical assertions) but I think the existence of specific functions
for the status and control registers makes it fairly obvious what is
going on.
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (i386_dr_low_set_addr): Replace check with
gdb_assert.
(i386_dr_low_get_addr): Remove vague comment.
* win32-i386-low.c (i386_dr_low_set_addr): Replace check with
gdb_assert.
Hi,
This patch is to handle a software watchpoint case that program returns
to caller's epilogue, and it causes the fail in thumb mode,
finish^M
Run till exit from #0 func () at gdb/testsuite/gdb.base/watchpoint-cond-gone.c:26^M
0x000001f6 in jumper ()^M
(gdb) FAIL: gdb.base/watchpoint-cond-gone.exp: Catch the no longer valid watchpoint
In the test, jumper calls func, and programs returns from func to
jumper's epilogue, IOW, the branch instruction is the last instruction
of jumper's function body.
jumper:
.....
0x000001f2 <+10>: bl 0x200 [1] <---- indirect call to func
0x000001f6 <+14>: mov sp, r7 [2] <---- start of the epilogue
0x000001f8 <+16>: add sp, #8
0x000001fa <+18>: pop {r7}
0x000001fc <+20>: pop {r0}
0x000001fe <+22>: bx r0
When the inferior returns from func back to jumper, it is expected
that an expression of a software watchpoint becomes out-of-scope.
GDB validates the expression by checking the corresponding frame,
but this check is guarded by gdbarch_in_function_epilogue_p. See
breakpoint.c:watchpoint_check.
It doesn't work in this case, because program returns from func's
epilogue back to jumper's epilogue [2], GDB thinks the program is
still within the epilogue, but in fact it goes to a different one.
When PC points at [2], the sp-restore instruction is to be
executed, so the stack frame isn't destroyed yet and we can still
use the frame mechanism reliably.
Note that when PC points to the first instruction of restoring SP,
it is part of epilogue, but we still return zero. When goes to
the next instruction, the backward scan will still match the
epilogue sequence correctly. The reason for doing this is to
handle the "return-to-epilogue" case.
What this patch does is to restrict the epilogue matching that let
GDB think the first SP restore instruction isn't part of the epilogue,
and fall back to use frame mechanism. We set 'found_stack_adjust'
zero before backward scan, and we've done this for arm mode
counterpart (arm_in_function_epilogue_p) too.
The patch is tested in arm-none-eabi and arm-none-linux-gnueabi with
various multilibs. OK to apply?
gdb:
2014-08-28 Yao Qi <yao@codesourcery.com>
* arm-tdep.c (thumb_in_function_epilogue_p): Don't set
found_stack_adjust in forward scan. Remove condition check
on found_stack_adjust which is always true. Indent the code.
Hi,
dwarf_decode_lines is called in two functions,
dwarf2_build_include_psymtabs and handle_DW_AT_stmt_list, in which, 1
is passed to argument 'want_line_info' and 'want_line_info' is a
conditional variable in dwarf_decode_lines. We can simplify it by
removing 'want_line_info' and propagating the constant 1 into
dwarf_decode_lines. This is what this patch does. This patch also
remove one line comment about WANT_LINE_INFO in
handle_DW_AT_stmt_list, as handle_DW_AT_stmt_list doesn't have such
argument.
gdb:
2014-08-28 Yao Qi <yao@codesourcery.com>
* dwarf2read.c (dwarf_decode_lines): Update declaration.
(handle_DW_AT_stmt_list): Remove comment about WANT_LINE_INFO.
(dwarf_decode_lines): Remove argument
want_line_info. Remove condition check on want_line_info.
Callers update.
The TUI terminal state becomes corrupted (e.g. key sequences such as
Alt_F and Alt_B no longer work) when one attaches to an inferior process
(via "run" or "attach") from within TUI. This terminal corruption
remains until you switch out of TUI mode.
This happens because the terminal state is not properly saved when
switching to and out from TUI mode. Although the functions tui_enable()
and tui_disable() both call the function target_terminal_save_ours() to
save the terminal state, this function is a no-op unless GDB has already
attached to an inferior process. This is because only the "native"
target has a useful implementation of target_terminal_save_ours()
(namely child_terminal_save_ours()) and we only have the "native" target
in our target vector if GDB has already attached to an inferior process.
So without an inferior process, switching to and from TUI mode does not
actually save the terminal state. Therefore when you attach to an
inferior process from within TUI mode, the proper terminal state is not
restored (after swapping from the inferior's terminal back to the GDB
terminal).
To fix this we just have to ensure that the terminal state is always
being properly saved when switching from and to TUI mode. To achieve
this, this patch removes the polymorphic function
target_terminal_save_ours() and replaces it with a regular function
gdb_save_tty_state() that always saves the terminal state.
Tested on x86_64-unknown-linux-gnu by running "make check", no new
regressions.
gdb/ChangeLog:
* target.h (struct target_ops::to_terminal_save_ours): Remove
declaration.
(target_terminal_save_ours): Remove macro.
* target-delegates.c: Regenerate.
* inf-child.c (inf_child_target): Don't set the nonexistent
field to_terminal_save_ours.
* inferior.h (child_terminal_save_ours): Remove declaration.
* terminal.h (gdb_save_tty_state): New declaration.
* inflow.c (child_terminal_save_ours): Rename to ...
(gdb_save_tty_state): ... this.
* tui/tui.c: Include terminal.h.
(tui_enable): Use gdb_save_tty_state instead of
target_terminal_save_ours.
(tui_disable): Likewise.
I read comment of scan_partial_symbols about NEED_PC and how *LOWPC
and *HIGHPC are updated:
DW_AT_ranges). If NEED_PC is set, then this function will set
*LOWPC and *HIGHPC to the lowest and highest PC values found in CU
and record the covered ranges in the addrmap.
NEED_PC is only used in the callee of scan_partial_symbols,
add_partial_subprogram,
if (pdi->tag == DW_TAG_subprogram)
{
if (pdi->has_pc_info)
{
if (pdi->lowpc < *lowpc)
*lowpc = pdi->lowpc;
if (pdi->highpc > *highpc)
*highpc = pdi->highpc;
if (need_pc)
*LOWPC and *HIGHPC is updated regardless of NEED_PC. When NEED_PC is
true, addrmap is updated. It would be clear to rename NEED_PC to
SET_ADDRMAP. That is what this patch does. Beside this, this patch
also adjust comments in related functions.
gdb:
2014-08-24 Yao Qi <yao@codesourcery.com>
* dwarf2read.c (scan_partial_symbols): Update comments.
Rename argument 'need_pc' with 'set_addrmap'.
（add_partial_namespace): Rename argument 'need_pc' with
'set_addrmap'.
(add_partial_module): Likewise.
(add_partial_subprogram): Likewise. Update comments.
(dwarf2_name): Fix typo.
I see the following fails on arm-none-eabi target,
print sn^M
$14 = 0x0 <_ftext>^M
(gdb) FAIL: gdb.python/py-value.exp: print sn
print sn^M
$14 = 0x0 <_ftext>^M
(gdb) FAIL: gdb.guile/scm-value.exp: print sn
as <_ftext> is unexpected. This patch is to set print symbol off to
avoid printing this.
gdb/testsuite:
2014-08-24 Yao Qi <yao@codesourcery.com>
* gdb.guile/scm-value.exp (test_lazy_strings): Set print
symbol off.
* gdb.python/py-value.exp (test_lazy_strings): Likewise.
See the description here:
https://sourceware.org/ml/gdb-patches/2014-08/msg00283.html
This patch keeps track of whether the current line has seen a
non-zero discriminator, and if so coalesces consecutive entries
for the same line (by ignoring all entries after the first).
gdb/ChangeLog:
PR 17276
* dwarf2read.c (dwarf_record_line_p): New function.
(dwarf_decode_lines_1): Ignore subsequent line number entries
for the same line if any entry had a non-zero discriminator.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-single-line-discriminators.S: New file.
* gdb.dwarf2/dw2-single-line-discriminators.c: New file.
* gdb.dwarf2/dw2-single-line-discriminators.exp: New file.
gdb/ChangeLog:
* buildsym.h (record_line_ftype): New typedef.
(record_line): Use it.
* dwarf2read.c (dwarf_record_line, dwarf_finish_line): New functions.
(dwarf_decode_lines_1): Call them.
Some gdb.python/*.exp tests fail because the .py files aren't copied
to the (remote) host. This patch is to copy needed .py files to host.
Most of gdb.python/*.exp tests do this.
As it is still controversial to delete *.py files on host, we don't do
that in this patch.
gdb/testsuite:
2014-08-22 Yao Qi <yao@codesourcery.com>
* gdb.python/py-finish-breakpoint.exp: Copy .py file to host.
* gdb.python/py-finish-breakpoint2.exp: Likewise.
* gdb.python/python.exp: Likewise. Use .py file on the host
instead of the build.
When GDB uses recent version of babeltrace, such as 1.2.x, we'll see
such error emitted from babeltrace library,
(gdb) target ctf .../gdb/testsuite/gdb.trace/actions.ctf
[error] Invalid CTF stream: content size is smaller than packet headers.
[error] Stream index creation error.
[error] Open file stream error.
The problem can be reproduce out of GDB too, using babeltrace,
$ babeltrace ./fake-packet.ctf/
[error] Invalid CTF stream: content size is smaller than packet headers.
[error] Stream index creation error.
[error] Open file stream error.
Recent babeltrace library becomes more strict on CTF, and complains
about one "faked packet" GDB adds, when saving trace data in ctf
format from GDB. babeltrace 1.1.0 has a bug that it can't read trace
data smaller than a certain size (see https://bugs.lttng.org/issues/450).
We workaround it in GDB to append some meaningless data in a faked
packet to make sure trace file is large enough (see ctf.c:ctf_end).
The babeltrace issue was fixed in 1.1.1 release. However, babeltrace
recent release (since 1.1.2) starts to complain about such faked
packet. Here is a table shows that whether faked packet or no faked
packet is "supported" by various babeltrace releases,
faked packet no faked packet
1.1.0 Yes No
1.1.1 Yes Yes
1.1.2 No Yes
1.2.0 No Yes
We decide to get rid of this workaround in GDB, and people can build GDB
with libbabeltrace >= 1.1.1. In this way, both configure and ctf.c is
simpler.
Run gdb.trace/* tests in the following combinations:
wo/ this pattch 1.1.0
w/ this patch 1.1.1
w/ this patch 1.1.2
w/ this patch 1.2.0
No test results change.
gdb:
2014-08-22 Yao Qi <yao@codesourcery.com>
* ctf.c (CTF_FILE_MIN_SIZE): Remove.
(ctf_end): Remove code.
Program received signal SIGABRT, Aborted.
[...]
(gdb) gcore foobar
Couldn't get registers: No such process.
(gdb) info threads
[...]
(gdb) gcore foobar
Saved corefile foobar
(gdb)
gcore tries to access the exited thread:
[Thread 0x7ffff7fce700 (LWP 6895) exited]
ptrace(PTRACE_GETREGS, 6895, 0, 0x7fff18167dd0) = -1 ESRCH (No such process)
Without the TRY_CATCH protection testsuite FAILs for:
gcore .../gdb/testsuite/gdb.threads/gcore-thread0.test
Cannot find new threads: debugger service failed
(gdb) FAIL: gdb.threads/gcore-thread.exp: save a zeroed-threads corefile
+
core .../gdb/testsuite/gdb.threads/gcore-thread0.test
".../gdb/testsuite/gdb.threads/gcore-thread0.test" is not a core dump: File format not recognized
(gdb) FAIL: gdb.threads/gcore-thread.exp: core0file: re-load generated corefile (bad file format)
Maybe the TRY_CATCH could be more inside update_thread_list().
Similar update_thread_list() call is IMO missing in procfs_make_note_section()
but I do not have where to verify that change.
gdb/ChangeLog
2014-08-21 Jan Kratochvil <jan.kratochvil@redhat.com>
* linux-tdep.c (linux_corefile_thread_callback): Ignore THREAD_EXITED.
(linux_make_corefile_notes): call update_thread_list, protected against
exceptions.
gdb/testsuite/ChangeLog
2014-08-21 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.threads/gcore-stale-thread.c: New file.
* gdb.threads/gcore-stale-thread.exp: New file.
This TODO has been stale for over 2 years. In bd5635a1 (1991), we
already see the comment, when we only had a bare attach_command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/*
* TODO:
* Should save/restore the tty state since it might be that the
* program to be debugged was started on this tty and it wants
* the tty in some state other than what we want. If it's running
* on another terminal or without a terminal, then saving and
* restoring the tty state is a harmless no-op.
* This only needs to be done if we are attaching to a process.
*/
/*
* attach_command --
* takes a program started up outside of gdb and ``attaches'' to it.
* This stops it cold in its tracks and allows us to start tracing it.
* For this to work, we must be able to send the process a
* signal and we must have the same effective uid as the program.
*/
void
attach_command (args, from_tty)
char *args;
int from_tty;
{
target_attach (args, from_tty);
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Later in b5a3d2aa (1992) target_terminal_init, etc. calls are added to
attach_command, and in 7e97eb28 (1992) we see:
+ /* If we attached to the process, we might or might not be sharing
+ a terminal. Avoid printing error msg if we are unable to set our
+ terminal's process group to his process group ID. */
+ if (!attach_flag) {
+ OOPSY ("ioctl TIOCSPGRP");
Clearly the TODO has been stale for a long while.
I considered preserving the text elsewhere, but then thought the
comments in inflow.c already have all the necessary info.
gdb/ChangeLog:
* infcmd.c (attach_command): Remove comment.
Checking whether the gcore command is included in the GDB build as
proxy for checking whether core dumping is supported by the target is
useless, as gcore.o has been in COMMON_OBS since git 9b4eba8e:
2009-10-26 Michael Snyder <msnyder@vmware.com>
Hui Zhu <teawater@gmail.com>
* Makefile.in (SFILES): Add gcore.c.
(COMMON_OBS): Add gcore.o.
* config/alpha/alpha-linux.mh (NATDEPFILES): Delete gcore.o.
* config/alpha/fbsd.mh (NATDEPFILES): Ditto.
...
IOW, the command is always included in the build.
Instead, nowadays, tests bail out if actually trying to generate a
core fails with an indication the target doesn't support it. See
gdb_gcore_cmd and callers.
Tested on x86_64 Fedora 20.
gdb/testsuite/ChangeLog:
* gdb.base/gcore-buffer-overflow.exp: Remove "help gcore" test.
* gdb.base/gcore-relro-pie.exp: Likewise.
* gdb.base/gcore-relro.exp: Likewise.
* gdb.base/gcore.exp: Likewise.
* gdb.base/print-symbol-loading.exp: Likewise.
* gdb.threads/gcore-thread.exp: Likewise.
* lib/gdb.exp (gdb_gcore_cmd): Don't expect "Undefined command".
Recent gdb code refactor changes LONGEST from a macro to a typedef,
thus the use of it in aarch64-linux-nat.c is no longer valid.
2014-08-21 Bin Cheng <bin.cheng@arm.com>
* aarch64-linux-nat.c (dr_changed_t): Change the type from
unsigned LONGEST to ULONGEST.
This integrates Jan Kratochvil's nice race reproducer from PR
testsuite/12649 into the testsuite infrustructure directly.
With this, one only has to do either 'make check-read1' or 'make check
READ1="1"' to preload the read1.so library into expect.
Currently only enabled for glibc/GNU systems, and if
build==host==target.
gdb/testsuite/ChangeLog:
* Makefile.in (EXTRA_RULES, CC): New variables, get from
configure.
(EXPECT): Handle READ1 being set.
(all): Depend on EXTRA_RULES.
(check-read1, expect-read1, read1.so, read1): New rules.
* README (Testsuite Parameters): Document the READ1 make variable.
(Race detection): New section.
* configure: Regenerate.
* configure.ac: If build==host==target, and running under a
GNU/glibc system, add read1 to the extra Makefile rules.
(EXTRA_RULES): AC_SUBST it.
* lib/read1.c: New file.
gdb/ChangeLog:
* Makefile.in (check-read1): New rule.
Consider an array described in the debugging information as being
a typedef of an array type for which there is a DW_AT_data_location
attribute. Trying to print the value of that array currently yields
incorrect element values. For instance:
(gdb) print foo.three_tdef
$1 = (6293760, 0, 6293772)
The problem occurs because we check for the data_location attribute
only on the typedef type, whereas we should be checking for the
typedef's target type. As a result, GDB erroneously thinks that
there is no data_location, and therefore starts reading the array's
content from the address of the descriptor instead of the data_location
address.
gdb/ChangeLog:
* value.c (value_from_contents_and_address): Strip resolved_type's
typedef layers before checking its TYPE_DATA_LOCATION.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/data-loc.exp: Add additional tests exercising
the handling of variables declared as a typedef to an array
which a DW_AT_data_location attribute.
