I noticed that make_hex_string does essentially the same thing as
bin2hex, and furthermore is only called in a single spot. This patch
removes make_hex_string.
Tested by the builtbot.
gdb/ChangeLog
2019-09-25 Tom Tromey <tom@tromey.com>
* python/py-objfile.c (objfpy_get_build_id): Use bin2hex.
* utils.h (make_hex_string): Don't declare.
* utils.c (make_hex_string): Remove.
I was looking at the implementation of this script keyword today and
couldn't remember why we do what we do in get_init_priority, because
the comments explain how the init_priority is encoded but don't say
why it is necessary to extract the priority and sort on that. So
after figuring out why (again), I wrote some more comments.
Then I simplified get_init_priority a little, adding some sanity
checking on the strtoul result. This actually makes get_init_priority
support sorting by numerical suffix more generally, but I figure this
feature would be better as a new keyword (without the .ctors/.dtors
special case), so haven't documented the extension.
* ld.texi (SORT_BY_ALIGNMENT): Reword slightly.
(SORT_BY_INIT_PRIORITY): Elucidate.
* ldlang.c: Include limits.h.
(get_init_priority): Comment. Change param to a section,
return an int. Sanity check priority digits. Support sorting
more sections with trailing digits. Return -1 on error.
(compare_section): Adjust.
On my openSUSE Leap 15.1 x86_64 Skylake system with the default (4.12) kernel,
I run into:
...
FAIL: gdb.base/gcore.exp: corefile restored all registers
...
The problem is that there's a difference in the mxcsr register value before
and after the gcore command:
...
- mxcsr 0x0 [ ]
+ mxcsr 0x400440 [ DAZ OM ]
...
This can be traced back to amd64_linux_nat_target::fetch_registers, where
xstateregs is partially initialized by the ptrace call:
...
char xstateregs[X86_XSTATE_MAX_SIZE];
struct iovec iov;
amd64_collect_xsave (regcache, -1, xstateregs, 0);
iov.iov_base = xstateregs;
iov.iov_len = sizeof (xstateregs);
if (ptrace (PTRACE_GETREGSET, tid,
(unsigned int) NT_X86_XSTATE, (long) &iov) < 0)
perror_with_name (_("Couldn't get extended state status"));
amd64_supply_xsave (regcache, -1, xstateregs);
...
after which amd64_supply_xsave is called.
The amd64_supply_xsave call is supposed to only use initialized parts of
xstateregs, but due to a kernel bug on intel skylake (fixed from 4.14 onwards
by commit 0852b374173b "x86/fpu: Add FPU state copying quirk to handle XRSTOR
failure on Intel Skylake CPUs") it can happen that the mxcsr part of
xstateregs is not initialized, while amd64_supply_xsave expects it to be
initialized, which explains the FAIL mentioned above.
Fix the undetermined behaviour by initializing xstateregs before calling
ptrace, which makes sure we get a 0x0 for mxcsr when this kernel bug occurs,
and which also happens to fix the FAIL.
Furthermore, add an xfail for this FAIL which triggers the same kernel bug:
...
FAIL: gdb.arch/amd64-init-x87-values.exp: check_setting_mxcsr_before_enable: \
check new value of MXCSR is still in place
...
Both FAILs pass when using a 5.3 kernel instead on the system mentioned above.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-09-24 Tom de Vries <tdevries@suse.de>
PR gdb/23815
* amd64-linux-nat.c (amd64_linux_nat_target::fetch_registers):
Initialize xstateregs before ptrace PTRACE_GETREGSET call.
gdb/testsuite/ChangeLog:
2019-09-24 Tom de Vries <tdevries@suse.de>
PR gdb/24598
* gdb.arch/amd64-init-x87-values.exp: Add xfail.
The fix for PR12848 introduced an off by one error in the mask, this corrected
the negative overflows but not the positive overflows. As a result the
conditional branch instructions accepted a too wide positive immediate which
resulted in it corrupting the instruction during encoding.
The relocation I believe has been incorrectly named, to be consistent with the
other relocations it should have been named BRANCH21 which is why the masks for
it are confusing.
I've replaced the masks with a function out_of_range_p which should make it
harder to make such mistakes.
The mask for BL/BLX on Armv6t+ is also wrong, the extended range is 25-bits
and so the mask should be checking for 24-bits for positive overflow.
gas/ChangeLog:
PR gas/24991
* config/tc-arm.c (out_of_range_p): New.
(md_apply_fix): Use it in BFD_RELOC_THUMB_PCREL_BRANCH9,
BFD_RELOC_THUMB_PCREL_BRANCH12, BFD_RELOC_THUMB_PCREL_BRANCH20,
BFD_RELOC_THUMB_PCREL_BRANCH23, BFD_RELOC_THUMB_PCREL_BRANCH25
* testsuite/gas/arm/pr24991.d: New test.
* testsuite/gas/arm/pr24991.l: New test.
* testsuite/gas/arm/pr24991.s: New test.
Using saved_format breaks when nm is presented with multiple object
files, some 32-bit and some 64-bit.
PR 25031
* nm.c (print_format_string): New.
(get_print_format): Delete saved_format. Move earlier.
(set_print_width): Call get_print_format.
(print_value): Use print_format_string.
This patch modifies assembler to accept the equivalent sized floating
and signless datatypes for VLDR instruction but as alias for the unsigned version.
gas/ChangeLog:
2019-09-23 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
* config/tc-arm.c (do_mve_vstr_vldr_RQ): Modify function to allow float
* and signless datatypes for few cases of VLDR instruction.
* testsuite/gas/arm/mve-vldr-bad-3.l: Modify.
* testsuite/gas/arm/mve-vldr-bad-3.s: Likewise.
* testsuite/gas/arm/mve-vstrldr-1.d: Likewise.
* testsuite/gas/arm/mve-vstrldr-1.s: Likewise.
This commit in binutils-gdb:
commit 830b67068c
Date: Fri Jul 12 09:53:02 2019 +0200
[readline] Fix heap-buffer-overflow in update_line
Which corresponds to this commit in upstream readline:
commit 31547b4ea4a1a904e1b08e2bc4b4ebd5042aedaa
Date: Mon Aug 5 10:24:27 2019 -0400
commit readline-20190805 snapshot
Introduced a use of an undefined variable, which can be seen using
valgrind:
$ valgrind --tool=memcheck gdb
GNU gdb (GDB) 8.3.50.20190918-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
==24924== Conditional jump or move depends on uninitialised value(s)
==24924== at 0x9986C3: rl_redisplay (display.c:710)
==24924== by 0x9839CE: readline_internal_setup (readline.c:447)
==24924== by 0x9A1C2B: _rl_callback_newline (callback.c:100)
==24924== by 0x9A1C85: rl_callback_handler_install (callback.c:111)
==24924== by 0x6195EB: gdb_rl_callback_handler_install(char const*) (event-top.c:319)
==24924== by 0x61975E: display_gdb_prompt(char const*) (event-top.c:409)
==24924== by 0x4FBFE3: cli_interp_base::pre_command_loop() (cli-interp.c:286)
==24924== by 0x6E53DA: interp_pre_command_loop(interp*) (interps.c:321)
==24924== by 0x731F30: captured_command_loop() (main.c:334)
==24924== by 0x733568: captured_main(void*) (main.c:1182)
==24924== by 0x7335CE: gdb_main(captured_main_args*) (main.c:1197)
==24924== by 0x41325D: main (gdb.c:32)
==24924==
(gdb)
The problem can be traced back to init_line_structures. The very
first time this function is ever called its MINSIZE parameter is
always 0 and the global LINE_SIZE is 1024. Prior to the above
mentioned commits we spot that the line_state variables have not yet
been initialised, and allocate them some new buffer, then we enter
this loop:
for (n = minsize; n < line_size; n++)
{
visible_line[n] = 0;
invisible_line[n] = 1;
}
which would initialise everything from the incoming minimum up to the
potentially extended upper line size.
The problem is that the above patches added a new condition that would
bump up the minsize like this:
if (minsize <= _rl_screenwidth) /* XXX - for gdb */
minsize = _rl_screenwidth + 1;
So, the first time this function is called the incoming MINSIZE is 0,
the LINE_SIZE global is 1024, and if the _rl_screenwidth is 80, we see
that MINSIZE will be pushed up to 80. We still notice that the line
state is uninitialised and allocate some buffers, then we enter the
initialisation loop:
for (n = minsize; n < line_size; n++)
{
visible_line[n] = 0;
invisible_line[n] = 1;
}
And initialise from 80 to 1023 i the newly allocated buffers, leaving
0 to 79 uninitialised.
To confirm this is an issue, if we then look at rl_redisplay we see
that a call to init_line_structures is followed first by a call to
rl_on_new_line, which does initialise visible_line[0], but not
invisible_line[0]. Later in rl_redisplay we have this logic:
if (visible_line[0] != invisible_line[0])
rl_display_fixed = 0;
The use of invisible_line[0] here will be undefined.
Considering how this variable was originally initialised before the
above patches, this patch modifies the initialisation loop in
init_line_structures, to use the original value of MINSIZE. With this
change the valgrind warning goes away.
readline/ChangeLog:
PR cli/24980
* display.c (init_line_structures): Initialise line_state using
original minsize value.
sim/testsuite/ChangeLog:
* configure: Regenerate.
sim/testsuite/sim/pru/ChangeLog:
* add.s: New test.
* allinsn.exp: New file.
* dmem-zero-pass.s: New test.
* dmem-zero-trap.s: New test.
* dram.s: New test.
* jmp.s: New test.
* loop-imm.s: New test.
* loop-reg.s: New test.
* mul.s: New test.
* subreg.s: New test.
* testutils.inc: New file.
This makes it safer to use in general, and also allows using it on a
background thread in the future.
Inspired by tromey's patch at:
1226cbdfa4
(however, implemented in a different way)
gdb/ChangeLog:
2019-09-23 Christian Biesinger <cbiesinger@google.com>
* ada-exp.y (write_object_remaining): Update.
* ada-lang.c (ada_decode): Return a std::string instead of a char*
and eliminate the static buffer.
(ada_decode_symbol): Update.
(ada_la_decode): Update.
(ada_sniff_from_mangled_name): Update.
(is_valid_name_for_wild_match): Update.
(ada_lookup_name_info::matches): Update and simplify.
(name_matches_regex): Update.
(ada_add_global_exceptions): Update.
* ada-lang.h (ada_decode): Update signature.
* ada-varobj.c (ada_varobj_describe_simple_array_child): Update.
* dwarf-index-write.c (debug_names::insert): Update.
In check_relocs, bfd_link_pic true means ld is producing a shared
library or a position independent executable. !bfd_link_pic means a
fixed position (ie. static) executable since the relocatable linking
case is excluded. So it is appropriate to continue using bfd_link_pic
when testing whether non-pcrelative relocations should be dynamic, and
!bfd_link_pic for the special case of ifunc in static executables.
However, -Bsymbolic shouldn't affect PIEs (they are executables so
none of their symbols should be overridden) and PIEs can support copy
relocations, thus bfd_link_executable should be used in those cases
rather than bfd_link_pic.
I've also removed the test of ELIMINATE_COPY_RELOCS in check_relocs.
We can sort out what to do regarding copy relocs later, which allows
the code in check_relocs to be simplified.
* elf64-ppc.c (ppc64_elf_check_relocs): Use bfd_link_executable
in choosing between different actions for shared library and
non-shared library cases. Delete ELIMINATE_COPY_RELOCS test.
(dec_dynrel_count): Likewise. Account for ifunc special case.
(ppc64_elf_adjust_dynamic_symbol): Copy relocs are for executables,
not non-pic.
(allocate_dynrelocs): Comment fixes. Delete ELIMINATE_COPY_RELOCS
test.
bfd/
* bfd-in.h: Move arm declaraions..
* cpu-arm.h: ..to here, new file..
* coff-arm.h: ..and here, new file..
* elf32-arm.h: ..and here, new file.
* cpu-arm.c: Include cpu-arm.h.
* coff-arm.c: Include cpu-arm.h and coff-arm.h.
* elf32-arm.c: Include cpu-arm.h and elf32-arm.h.
* pe-arm.c: Move function rename defines later.
* pe-arm-wince.c: Likewise and include sysdep.h and bfd.h early.
* bfd-in2.h: Regenerate.
gas/
* config/tc-arm.c: Include cpu-arm.h.
ld/
* emultempl/armelf.em: Include elf32-arm.h.
* emultempl/pe.em: Move func defines later and include coff-arm.h.
Pointer comparisons after adding an offset just don't work to catch
overflow when the offset is a larger type than the pointer.
PR 25018
* dwarf.c (get_type_signedness): Delete ineffective pointer
comparison check. Properly range check uvalue offset on
recursive call.
(read_and_display_attr_value): Range check uvalue offset before
calling get_type_signedness.
gcc10 on x86_64 and powerpc64le recognises that the loop in
Foo::operator= can be turned into a call to memmove, which then
results in an undefined symbol when linking. Avoid that by making the
loop smaller.
* testsuite/ld-srec/sr3.cc (FOO_MSG_LEN): Set to 4.
We currently run into:
...
248 n = callee1 (n + l5);
(gdb) PASS: gdb.base/restore.exp: caller5 calls callee1; return callee now
print l1
$51 = <optimized out>
(gdb) FAIL: gdb.base/restore.exp: caller5 calls callee1; return restored l1 \
to 32492
...
The problem is that we try to access the value of l1 in function caller5, but
variable l1 has no DW_AT_location attribute. Since l1 is declared using the
register keyword, it's valid for gcc to emit no DW_AT_location at -O0.
Change the FAIL into an UNSUPPORTED.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-22 Tom de Vries <tdevries@suse.de>
* gdb.base/restore.exp: Allow register variables to be optimized out at
-O0.
These int fields have been converted to bool, so their doc should say
"true" and not "nonzero".
gdb/ChangeLog:
* breakpoint.h (bp_location) <inserted, permanent, duplicate>:
Change "nonzero" to "true" in documentation.
All implementations of either function use it for the same purpose (except
Darwin, which is a no-op): to prefer a symbol in the current objfile over
symbols with the same name in other objfiles. There does not seem to be a
reason to have both mechanisms for that purpose.
gdb/ChangeLog:
2019-09-20 Christian Biesinger <cbiesinger@google.com>
* solib-darwin.c (darwin_lookup_lib_symbol): Remove.
(_initialize_darwin_solib): Don't set
darwin_so_ops.lookup_lib_global_symbol.
* solib-svr4.c (set_solib_svr4_fetch_link_map_offsets): Call
set_gdbarch_iterate_over_objfiles_in_search_order.
(elf_lookup_lib_symbol): Rename to...
(svr4_iterate_over_objfiles_in_search_order): this, and update
to iterate semantics.
(_initialize_svr4_solib): Don't set lookup_lib_global_symbol.
* solib.c (solib_global_lookup): Remove.
* solist.h (struct target_so_ops): Remove lookup_lib_global_symbol.
(solib_global_lookup): Remove.
* symtab.c (lookup_global_or_static_symbol): Remove call to
solib_global_lookup.
Instead of declaring debug_threads and using_threads in several
.c files, declare them in debug.h.
gdb/gdbserver/ChangeLog:
2019-09-20 Christian Biesinger <cbiesinger@google.com>
* debug.c (debug_threads): Remove comment in favor of the header.
* debug.h (using_threads): Add declaration.
(debug_threads): Add comment.
* linux-aarch64-low.c: Include debug.h and remove declaration of
debug_threads.
* nto-low.c: Likewise.
* remote-utils.c: Likewise.
* thread-db.c: Likewise.
This is a followup on the following commit...
commit b4be1b0648
Date: Wed Mar 13 15:13:03 2019 -0400
Subject: Fix MI output for multi-location breakpoints
... which mistakenly added NEWS entries in the "in gdb-8.3" section,
rather than in the "since gdb-8.3" one.
gdb/ChangeLog:
* NEWS: Move entries about default MI version now being
version 3, and about the GDB/MI fix for multi-location
breakpoints to the "since GDB 8.3" section.
