This new script has one small snafoo, which prevented the $host_alias
and $target_alias from being expanded during the generation of the
version.c file. As a result, the version info yields:
This GDB was configured as "--host=$host_alias --target=$target_alias".
^^^^^^^^^^^ ^^^^^^^^^^^^^
This patch fixes this issue.
gdb/ChangeLog:
* common/create-version.sh: Fix expansion of $host_alias
and $target_alias in generation of HOST_NAME and TARGET_NAME
(resp.).
Right now there are two nightly commits to update a file in the tree
with the current date. One commit is for BFD, one is for gdb.
It seems unnecessary to me to do this twice. We can make do with a
single such commit.
This patch changes gdb in a minimal way to reuse the BFD date -- it
extracts it from bfd/version.h and changes version.in to use the
placeholder string "DATE" for those times when a date is wanted.
I propose removing the cron job that updates the version on trunk, and
then check in this patch.
For release branches, we can keep the cron job, but just tell it to
rewrite bfd/version.h. I believe this is a simple change in the
crontab -- the script will work just fine on this file.
This also moves version.in and version.h into common/, to reflect
their shared status; and updates gdbserver to use version.h besides.
* common/create-version.sh: New file.
* Makefile.in (version.c): Use bfd/version.h, common/version.in,
create-version.sh.
(HFILES_NO_SRCDIR): Use common/version.h.
* version.in: Move to ...
* common/version.in: ... here. Replace date with "DATE".
* version.h: Move to ...
* common/version.h: ... here.
gdbserver:
* Makefile.in (version.c): Use bfd/version.h, common/version.in,
create-version.sh.
(version.o): Remove.
* gdbreplay.c: Include version.h.
(version, host_name): Don't declare.
* server.h: Include version.h.
(version, host_name): Don't declare.
doc:
* Makefile.in (POD2MAN1, POD2MAN5): Use version.subst.
(GDBvn.texi): Use version.subst.
(version.subst): New target.
(mostlyclean): Remove version.subst.
This patch is the result of re-running the copyright.py script
in GDB, after we modified it to stop ignoring some files in
gdb/gnulib that should have been updated earlier this year.
gdb/ChangeLog:
* gdb/gnulib/Makefile.in: Update date in copyright header.
* gdb/gnulib/configure.ac: Ditto.
* gdb/gnulib/update-gnulib.sh: Ditto.
The script was excluding all of gdb/gnulib but this is no longer
correct, ever since we moved the imported files to gdb/gnulib/import.
As a result, a number of files (Makefile, etc, including this script
itself) did not have their copyright header updated. This fixes
the problem.
gdb/ChangeLog:
* copyright.py (EXCLUDE_LIST): Replace "gdb/gnulib" by
"gdb/gnulib/import".
Most modern systems have frexpl and gnulib provides an implementation
for those that don't, so use it instead of the generic but inaccurate
ldfrexp.
gdb/ChangeLog:
2013-06-21 Will Newton <will.newton@linaro.org>
* doublest.c (ldfrexp): Remove function.
(convert_doublest_to_floatformat): Call frexpl instead of
ldfrexp.
* dwarf2read.c (try_open_dwop_file): New arg search_cwd.
All callers updated.
(open_dwp_file): If we can't find the dwp file, search the basename
in debug-file-directory.
This patch adds an option --skip-unavailable to MI command
-data-list-register-values, so that unavailable registers are not
displayed (on the context of traceframes).
The old -data-list-register-values command behaves like
-data-list-register-values x 0 8
^done,register-values=[{number="0",value="<unavailable>"},{number="8",value="0x80483de"}]
With this patch, an option --skip-unavailable is added,
-data-list-register-values --skip-unavailable x 0 8
^done,register-values=[{number="8",value="0x80483de"}]
gdb:
2013-06-20 Pedro Alves <pedro@codesourcery.com>
Yao Qi <yao@codesourcery.com>
* NEWS: Mention the new option '--skip-unavailable' of command
-data-list-register-values.
* mi/mi-main.c (mi_cmd_data_list_register_values): Accept the
--skip-unavailable option. Adjust to use output_register.
(output_register): Add new 'skip_unavailable' parameter.
Handle it.
gdb/doc:
2013-06-20 Pedro Alves <pedro@codesourcery.com>
* gdb.texinfo (GDB/MI Data Manipulation)
<-data-list-register-values>: Document the --skip-unavailable
option.
gdb/testsuite:
2013-06-20 Yao Qi <yao@codesourcery.com>
* gdb.trace/mi-trace-unavailable.exp: Set tracepoint on 'foo'
and set an action.
(test_trace_unavailable): Test command -data-list-register-values
in the context of traceframe and with option --skip-unavailable.
* gdb.trace/trace-unavailable.c (foo): New.
(main): Call it.
* gdb.mi/gdb2549.exp: Update matching pattern.
We've currently got 3 files doing open coded implementations of cpuid.
Each has its own set of workarounds and varying levels of how well
they're written and are generally hardcoded to specific cpuid functions.
If you try to build the latest gdb as a PIE on an i386 system, the build
will fail because one of them lacks PIC workarounds (wrt ebx).
Specifically, we have:
common/linux-btrace.c:
two copies of cpuid asm w/specific args, one has no workarounds
while the other implicitly does to avoid memcpy
go32-nat.c:
two copies of cpuid asm w/specific args, one has workarounds to
avoid memcpy
gdb/testsuite/gdb.arch/i386-cpuid.h:
one general cpuid asm w/many workarounds copied from older gcc
Fortunately, that last header there is pretty damn good -- it handles
lots of edge cases, the code is nice & tight (uses gcc asm operands
rather than manual movs), and is already almost a general library type
header. It's also the basis of what is now the public cpuid.h that is
shipped with gcc-4.3+.
So what I've done is pull that test header out and into gdb/common/
(not sure if there's a better place), synced to the version found in
gcc-4.8.0, put a wrapper API around it, and then cut over all the
existing call points to this new header.
Since the func already has support for "is cpuid supported on this proc",
it makes it trivial to push the i386/x86_64 ifdefs down into this wrapper
API too. Now it can be safely used for all targets and gcc will elide
the unused code for us.
I've verified the gdb.arch testsuite still passes, and this code compiles
for an armv7a host as well as x86_64. The go32-nat code has been left
ifdef-ed out until someone can test & verify the new stuff works (and if
it doesn't, figure out how to make the new code work).
URL: https://bugs.gentoo.org/467806
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
before using it.
(dw2_expand_symtabs_matching): Fix symbol kind validity check.
Move test of cu_index closer to use. Print complaint if cu_index
is bad.
This patch fixes a cleanup leak in macho_symfile_read (symbol_table):
symbol_table = (asymbol **) xmalloc (storage_needed);
make_cleanup (xfree, symbol_table);
Unfortunately, fixing the leak alone triggers a crash which occurs
while loading the symbols from an executable:
% gdb
(gdb) file g_exe
[SIGSEGV]
The crash is caused by the fact that performing the cleanup
right after the call to macho_symtab_read, as currently done,
is too early.
Indeed, references to this symbol_table get saved in the oso_vector
global during the call to macho_symtab_read via calls to
macho_register_oso, and those references then get accessed
later on, when processing all the OSOs that got pushed (see
call to macho_symfile_read_all_oso).
This patch prevents this by using one single cleanup queue for
the entire function, rather than having additional separate
cleanup queues (Eg: for the handling of the minimal symbols),
thus preventing the premature free'ing of the minimal_symbols
array.
Secondly, this patch takes this opportunity for avoiding the use
of the oso_vector global, thus making it simpler to track its
lifetime.
gdb/ChangeLog:
* machoread.c (oso_vector): Delete this global.
(macho_register_oso): Add new parameter "oso_vector_ptr".
Use it instead of the "oso_vector" global.
(macho_symtab_read, macho_symfile_read_all_oso): Likewise.
(macho_symfile_read): Use a local oso_vector, to be free'ed
at the end of this function, in place of the old "oso_vector"
global. Update various function calls accordingly. Use one
single cleanup chain for the entire function.
This patch fixes a case of multiple calls freeing the same data
while free-ing objfiles that have child objfiles (separate debug
info, as is the case on Darwin targets).
Following the code, free_objfile_separate_debug iterates over
all child objfiles of the parent objfile, calling free_objfile:
for (child = objfile->separate_debug_objfile; child;)
{
struct objfile *next_child = child->separate_debug_objfile_link;
free_objfile (child);
child = next_child;
}
This causes, among other things, the free'ing of the child objfile's
private data:
/* Discard any data modules have associated with the objfile. The function
still may reference objfile->obfd. */
objfile_free_data (objfile);
This indirectly calls(back) dwarf2_per_objfile_free, which tries
to free the dwarf2read-specific data by using the dwarf2_per_objfile
global, eg:
for (ix = 0; ix < dwarf2_per_objfile->n_comp_units; ++ix)
Even if we were lucky enough the first time around that this global
actually corresponds to the objfile being destroyed, the global
will still have the same value at the second iteration, and thus
become dangling. Indeed, after dwarf2_per_objfile_free returns
eventually back to free_objfile, free_objfile then deallocates
its objfile_obstack, where the dwarf2_per_objfile is allocated.
Ironically, there should be no need to access that global at all,
here, since the data is passed as an argument of the callback.
And it looks like the dwo/dwp/[...]-handling code is in fact already
using that argument, rather than the global.
This patch thus fixes the problem by doing the same, replacing
all references to DWARF2_PER_OBJFILE by uses of DATA instead.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_per_objfile): Replace uses of
DWARF2_PER_OBJFILE by uses of DATA instead.
This fixes PR cli/15603.
The bug here is that when a software watchpoint is being used, gdb
will stop responding to C-c. This is a regression caused by the
"catch signal" patch.
The problem is that software watchpoints always end up on the bpstat
list. However, this makes bpstat_explains_signal return
BPSTAT_SIGNAL_HIDE, causing infrun to think that the signal is not a
"random signal".
The fix is to change bpstat_explains_signal to handle this better. I
chose to do it in a "clean API" way, by passing the signal value to
bpstat_explains_signal and then adding an explains_signal method for
watchpoints, which handles the specifics.
Built and regtested on x86-64 Fedora 18.
New test case included.
* break-catch-sig.c (signal_catchpoint_explains_signal): Add 'sig'
argument.
* breakpoint.c (bpstat_explains_signal): Add 'sig' argument.
Special case signals other than GDB_SIGNAL_TRAP.
(explains_signal_watchpoint): New function.
(base_breakpoint_explains_signal): Add 'sig' argument.
(initialize_breakpoint_ops): Set 'explains_signal' method for
watchpoints.
* breakpoint.h (struct breakpoint_ops) <explains_signal>: Add
signal argument.
(bpstat_explains_signal): Likewise.
* infrun.c (handle_syscall_event, handle_inferior_event): Update.
* gdb.base/random-signal.c: New file.
* gdb.base/random-signal.exp: New file.
The skip test currently relies on the order of evaluation of
arguments which is not defined. Use the comma operator where
order is defined instead.
gdb/testsuite/ChangeLog:
2013-06-18 Will Newton <will.newton@linaro.org>
* gdb.base/skip.c: Use comma to evaluate results of foo()
and bar() before passing to baz().
* gdb.base/skip.c: baz() now takes one argument instead of
two.
PR symtab/15391 is a failure with the DW_OP_GNU_implicit_pointer
feature.
I tracked it down to a logic error in read_pieced_value. The code
truncates this_size_bits according to the type size and offset too
early -- it should do it after taking bits_to_skip into account.
This patch fixes the bug.
While testing this, I also tripped across a latent bug because
indirect_pieced_value does not sign-extend where needed. This patch
fixes this bug as well.
Finally, Pedro pointed out that a previous version implemented sign
extension incorrectly. This version introduces a new gdb_sign_extend
function for this. A couple of notes on this function:
* It has the gdb_ prefix to avoid clashes with various libraries that
felt free to avoid proper namespacing. There is a "sign_extend"
function in a Tile GX header, in an SOM-related BFD header (and in
sh64-tdep.c and as a macro in arm-wince-tdep.c, but those are
ours...)
* I looked at all the sign extensions in gdb and didn't see ones that
I felt comfortable converting to use this function; in large part
because I don't have a good way to test the conversion.
Built and regtested on x86-64 Fedora 18. New test cases included;
this required a minor addition to the DWARF assembler. Note that the
DWARF CU made by implptrpiece.exp uses a funny pointer size in order
to show the sign-extension bug on all platforms.
* dwarf2loc.c (read_pieced_value): Truncate this_size_bits
after taking bits_to_skip into account. Sign extend byte_offset.
* utils.h (gdb_sign_extend): Declare.
* utils.c (gdb_sign_extend): New function.
* gdb.dwarf2/implptrpiece.exp: New file.
* gdb.dwarf2/implptrconst.exp (d): New variable.
Print d.
* lib/dwarf2.exp (Dwarf::_location): Handle DW_OP_piece.
python-selftest.exp fails with an error when using the
native-gdbserver.exp board.
The bug is that the selftest code doesn't work in this situation. It
never has.
This patch fixes the problem by pushing the needed check into
do_self_tests. This helps prevent the problem in the future.
* lib/selftest-support.exp (do_self_tests): Reject remote or
non-native targets.
* gdb.gdb/complaints.exp: Remove check.
* gdb.gdb/observer.exp: Remove check.
* gdb.gdb/xfullpath.exp: Remove check.
* gdb.gdb/complaints.exp: Remove check.
This fixes the regressions reported at
<http://sourceware.org/ml/gdb-patches/2013-06/msg00280.html>:
$ runtest-gdbserver gdb.base/siginfo-obj.exp gdb.base/siginfo-thread.exp gdb.threads/siginfo-threads.exp
Running ./gdb.base/siginfo-thread.exp ...
FAIL: gdb.base/siginfo-thread.exp: p ssi_addr
Running ./gdb.threads/siginfo-threads.exp ...
FAIL: gdb.threads/siginfo-threads.exp: signal 0 si_pid
FAIL: gdb.threads/siginfo-threads.exp: signal 1 si_pid
FAIL: gdb.threads/siginfo-threads.exp: signal 2 si_pid
FAIL: gdb.threads/siginfo-threads.exp: signal 3 si_pid
Running ./gdb.base/siginfo-obj.exp ...
FAIL: gdb.base/siginfo-obj.exp: p ssi_addr
FAIL: gdb.base/siginfo-obj.exp: p ssi_addr
The multi-arch patch made GDBserver do the the wrong siginfo layout
conversion, because most uses of `linux_is_elf64' were removed, and it
ended up never set. A global really is the wrong thing to use as
elf64-ness is a per-process property; `linux_is_elf64' was just
accidentally left behind.
Tested on x86_64 Fedora 17.
gdb/gdbserver/
2013-06-12 Pedro Alves <palves@redhat.com>
* linux-x86-low.c (linux_is_elf64): Delete global.
(x86_siginfo_fixup): Replace reference to `linux_is_elf64' global
with local linux_pid_exe_is_elf_64_file use.
There's no need for every arch to pre-allocate disabled_regsets.
Chances are the array won't be used.
(I have a hunch that with some more work we could dispense with
initialize_regsets_info.)
Tested on x86_64 Fedora 17 w/ -lmcheck.
gdb/gdbserver/
2013-06-11 Pedro Alves <palves@redhat.com>
* linux-low.c (regset_disabled, disable_regset): New functions.
(regsets_fetch_inferior_registers)
(regsets_store_inferior_registers): Use them.
(initialize_regsets_info); Don't allocate the disabled_regsets
array here.
* linux-low.h (struct regsets_info) <disabled_regsets>: Extend
comment.
This fixes the regression reported at
<http://sourceware.org/ml/gdb-patches/2013-06/msg00185.html>.
GDBserver was reaching:
static int
regsets_fetch_inferior_registers (struct regsets_info *regsets_info,
struct regcache *regcache)
{
struct regset_info *regset;
int saw_general_regs = 0;
int pid;
struct iovec iov;
regset = regsets_info->regsets;
pid = lwpid_of (get_thread_lwp (current_inferior));
while (regset->size >= 0)
{
void *buf, *data;
int nt_type, res;
if (regset->size == 0
|| regsets_info->disabled_regsets[regset - regsets_info->regsets])
{
>>>>>>> regset ++; <<<<<<< HERE
continue;
}
Because info->disabled_regsets[] was not being initialized, and that
causes all sorts of wrong.
gdb/gdbserver/
2013-06-11 Pedro Alves <palves@redhat.com>
* linux-low.c (initialize_regsets_info): Use xcalloc instead of
xmalloc.
