Alan Modra [Thu, 5 Oct 2017 07:02:18 +0000 (17:32 +1030)]
PR22239 - invalid memory read in display_debug_frames
Pointer comparisons have traps for the unwary. After adding a large
unknown value to "start", the test "start < end" depends on where
"start" is originally in memory.
PR 22239
* dwarf.c (read_cie): Don't compare "start" and "end" pointers
after adding a possibly wild length to "start", compare the length
to the difference of the pointers instead. Remove now redundant
"negative" length test.
Pedro Alves [Wed, 4 Oct 2017 13:20:51 +0000 (14:20 +0100)]
bfd_set_input_error
A downside to the 2017-10-04 PR22245 fix is that bfd_set_error can now
silently accept invalid errors if/when someone passes the a value of
the wrong enumeration type, which previously would be caught by the
-Wenum-conversion warning.
Alan Modra [Tue, 3 Oct 2017 23:23:53 +0000 (09:53 +1030)]
PR21167, relocation sections not included in groups
This fixes a wart I've known about for years, but haven't done
anything about because BFD treats relocation sections as an adjunct to
the section they relocate. SHF_GROUP on the section thus implicitly
applies to its relocation section(s), but it is an error that the
reloc sections aren't part of the group.
Like many patches to gas, this wasn't as straightforward as it could
be due to a number of backends, i386, cr16 and others, removing relocs
in tc_get_reloc rather than marking them as "done" earlier in
md_apply_reloc. So it isn't possible for the group support to
reliably detect the presence of relocs by looking at fixups earlier
than write_relocs. However the group support needs to create
signature symbols, and that must be done before the symbol table is
frozen, before write_relocs. So split off the group sizing from
elf_adjust_symtab and put it in elf_frob_file_after_relocs.
bfd/
PR 21167
* elf.c (_bfd_elf_setup_sections): Don't trim reloc sections from
groups.
(_bfd_elf_init_reloc_shdr): Pass sec_hdr, use it to copy SHF_GROUP
flag from section.
(elf_fake_sections): Adjust calls. Exit immediately on failure.
(bfd_elf_set_group_contents): Add associated reloc section indices
to group contents
gas/
PR 21167
* config/obj-elf.c (struct group_list): Delete elt_count.
(groups): New static.
(build_group_lists): Don't count elements.
(elf_adjust_symtab): Use groups rather than auto list. Set up
pointer from group member to SHT_GROUP section. Don't size
SHT_GROUP section or clean up here..
(elf_frob_file_after_relocs): ..do so here instead.
* testsuite/gas/arc/jli-1.d,
* testsuite/gas/elf/groupautob.d,
* testsuite/gas/mips/compact-eh-eb-2.d,
* testsuite/gas/mips/compact-eh-eb-5.d,
* testsuite/gas/mips/compact-eh-el-2.d,
* testsuite/gas/mips/compact-eh-el-5.d: Adjust.
ld/
PR 21167
* testsuite/ld-elf/group9b.d: Adjust for relocs included in group.
Pedro Alves [Wed, 4 Oct 2017 17:21:10 +0000 (18:21 +0100)]
Fix "Remote 'g' packet reply is too long" problems with multiple inferiors
When debugging two inferiors (or more) against gdbserver, and the
inferiors have different architectures, such as e.g., on x86_64
GNU/Linux and one inferior is 64-bit while the other is 32-bit, then
GDB can get confused with the different architectures in a couple
spots.
In both cases I ran into, GDB incorrectly ended up using the
architecture of whatever happens to be the selected inferior instead
of the architecture of some other given inferior:
#1 - When parsing the expedited registers in stop replies.
#2 - In the default implementation of the target_thread_architecture
target method.
These resulted in instances of the infamous "Remote 'g' packet reply
is too long" error. For example, with the test added in this commit,
we get:
~~~
Continuing.
Remote 'g' packet reply is too long (expected 440 bytes, got 816 bytes): ad064000000000000[snip]
(gdb) FAIL: gdb.multi/multi-arch.exp: inf1 event with inf2 selected: continue to hello_loop
c
Continuing.
Truncated register 50 in remote 'g' packet
(gdb) PASS: gdb.multi/multi-arch.exp: inf2 event with inf1 selected: c
~~~
This commit fixes that.
gdb/ChangeLog:
2017-10-04 Pedro Alves <palves@redhat.com>
* remote.c (get_remote_arch_state): New 'gdbarch' parameter. Use
it instead of target_gdbarch.
(get_remote_state, get_remote_packet_size): Adjust
get_remote_arch_state calls, passing down target_gdbarch
explicitly.
(packet_reg_from_regnum, packet_reg_from_pnum): New parameter
'gdbarch' and use it instead of target_gdbarch.
(get_memory_packet_size): Adjust get_remote_arch_state calls,
passing down target_gdbarch explicitly.
(struct stop_reply) <arch>: New field.
(remote_parse_stop_reply): Use the stopped thread's architecture,
not the current inferior's. Save the architecture in the
stop_reply.
(process_stop_reply): Use the stop reply's architecture.
(process_g_packet, remote_fetch_registers)
(remote_prepare_to_store, store_registers_using_G)
(remote_store_registers): Adjust get_remote_arch_state calls,
using the regcache's architecture.
(remote_get_trace_status): Adjust get_remote_arch_state calls,
passing down target_gdbarch explicitly.
* spu-multiarch.c (spu_thread_architecture): Defer to the target
beneath instead of calling target_gdbarch.
* target.c (default_thread_architecture): Use the specified
inferior's architecture, instead of the current inferior's
architecture (via target_gdbarch).
gdb/testsuite/ChangeLog:
2017-10-04 Pedro Alves <palves@redhat.com>
* gdb.multi/hangout.c: Include <unistd.h>.
(hangout_loop): New function.
(main): Call alarm. Call hangout_loop in a loop.
* gdb.multi/hello.c: Include <unistd.h>.
(hello_loop): New function.
(main): Call alarm. Call hangout_loop in a loop.
* gdb.multi/multi-arch.exp: Test running to a breakpoint one
inferior with the other selected.
This is because target_gdbarch is really just
current_inferior()->gdbarch, and it's wrong to return that
architecture when the inferior of the passed in PTID is NOT the
current inferior -- the inferior for PTID may be running a different
architecture. E.g., a mix of 64-bit and 32-bit inferiors in the same
debug session.
Doing that change above however exposes a problem in "maint print
registers", caught be the testsuite:
-PASS: gdb.base/maint.exp: maint print registers
+FAIL: gdb.base/maint.exp: maint print registers (GDB internal error)
...
gdb/inferior.c:309: internal-error: inferior* find_inferior_pid(int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
The call stack looks like this:
#0 0x000000000068b707 in internal_error(char const*, int, char const*, ...) (file=0xa9b958 "gdb/inferior.c", line=309, fmt=0xa9b8e0 "%s: Assertion `%s' failed.") at gdb/common/errors.c:54
#1 0x00000000006e1c40 in find_inferior_pid(int) (pid=0) at gdb/inferior.c:309
#2 0x00000000006e1c8d in find_inferior_ptid(ptid_t) (ptid=...) at gdb/inferior.c:323
#3 0x00000000007c18dc in default_thread_architecture(target_ops*, ptid_t) (ops=0xf86d60 <dummy_target>, ptid=...)
at gdb/target.c:3134
#4 0x00000000007b5414 in delegate_thread_architecture(target_ops*, ptid_t) (self=0xf86d60 <dummy_target>, arg1=...)
at gdb/target-delegates.c:2527
#5 0x00000000007647b3 in get_thread_regcache(ptid_t) (ptid=...) at gdb/regcache.c:466
#6 0x00000000007647ff in get_current_regcache() () at gdb/regcache.c:475
#7 0x0000000000767495 in regcache_print(char const*, regcache_dump_what) (args=0x0, what_to_dump=regcache_dump_none)
at gdb/regcache.c:1599
#8 0x0000000000767550 in maintenance_print_registers(char const*, int) (args=0x0, from_tty=1)
at gdb/regcache.c:1613
I.e., the test does "maint print registers" while the inferior is not
running yet. This is expected to work, and there's already a hack in
get_thread_arch_regcache to make it work.
Instead of pilling on hacks in the internal of regcache and
target_ops, this commit moves the null_ptid special casing to where it
belongs -- higher up in the call chain in the implementation of "maint
print registers" & co directly.
gdb/ChangeLog:
2017-10-04 Pedro Alves <palves@redhat.com>
* regcache.c (get_thread_arch_regcache): Remove null_ptid special
case.
(regcache_print): Handle !target_has_registers here instead.
/* For the benefit of "maint print registers" & co when debugging an
executable, allow dumping the regcache even when there is no
thread selected (target_thread_address_space internal-errors if
no address space is found). Note that normal user commands will
fail higher up on the call stack due to no
target_has_registers. */
aspace = (ptid_equal (null_ptid, ptid)
? NULL
: target_thread_address_space (ptid));
i.e., it'll no longer be possible to try to build a regcache for
null_ptid. That change alone would regress the gdbarch self tests
though, causing this:
(gdb) maintenance selftest
[...]
Running selftest register_to_value.
src/gdb/inferior.c:309: internal-error: inferior* find_inferior_pid(int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.gdb/unittest.exp: maintenance selftest (GDB internal error)
The problem is that the way the mocking environment for those unit
tests is written is a bit fragile: it creates a special purpose
regcache (and sentinel's frame), using whatever is the current
inferior_ptid (usually null_ptid), and assumes get_current_regcache
will find that in the regcache::current_regcache list.
This commit changes the way the mock environment is created. It
eliminates the special regcache and frame and instead creates a fuller
mock environment, with a custom mock target_ops, and then a mock
inferior and thread "running" on that target.
If there's already a running target when you type "maint selftest",
then we error out, instead of pushing a new target on top of the
existing one (and thus killing the debug session). This results in:
(gdb) maint selftest
(...)
Self test failed: arch i386: target already pushed
Self test failed: arch i386:x86-64: target already pushed
Self test failed: arch i386:x64-32: target already pushed
Self test failed: arch i8086: target already pushed
Self test failed: arch i386:intel: target already pushed
Self test failed: arch i386:x86-64:intel: target already pushed
Self test failed: arch i386:x64-32:intel: target already pushed
Self test failed: arch i386:nacl: target already pushed
Self test failed: arch i386:x86-64:nacl: target already pushed
Self test failed: arch i386:x64-32:nacl: target already pushed
Self test failed: self-test failed at /home/pedro/gdb/mygit/src/gdb/selftest-arch.c:86
(...)
Ran 19 unit tests, 1 failed
I think that's OK, because self tests are really meant to be run from
a clean state right after GDB is started. I'm adding that erroring
out just as safe measure just in case someone types "maint selftest"
on the command line while already debugging something (as I've done
it).
(In my multi-target branch, where this patch originated from, we don't
actually need to error out, because there each inferior has its own
target stack).
Also, note that the current code was doing:
current_inferior()->gdbarch = gdbarch;
without taking care to restore the previous gdbarch. This means that
GDB's state was being left inconsistent after running the self tests,
further supporting the point that there's probably not much
expectation that mixing "maint selftests" and regular debugging in the
same GDB invocation really works. This patch fixes that, regardless.
gdb/ChangeLog:
2017-10-04 Pedro Alves <palves@redhat.com>
* frame.c (create_test_frame): Delete.
* frame.h (create_test_frame): Delete.
* gdbarch-selftests.c: Include gdbthread.h and target.h.
(class regcache_test): Delete.
(test_target_has_registers, test_target_has_stack)
(test_target_has_memory, test_target_prepare_to_store)
(test_target_store_registers): New functions.
(test_target_ops): New class.
(register_to_value_test): Error out if there's already a
process_stratum (or higher) target pushed. Create a fuller mock
environment, with mock target_ops, inferior, address space, thread
and inferior_ptid.
* progspace.c (struct address_space): Move to ...
* progspace.h (struct address_space): ... here.
* regcache.h (regcache::~regcache, regcache::raw_write)
[GDB_SELF_TEST]: No longer virtual.
changed the logic of the "-list-thread-groups --available" by mistake
when a pid is passed. It prints all the processes except the one
specified by the given pid. The correct behavior is to only print the
process corresponding to that pid. this patch fixes that and adds a test.
Pedro Alves [Wed, 4 Oct 2017 10:07:28 +0000 (11:07 +0100)]
Move code out of 'between TRY and CATCH'
I tried building GDB with TRY/CATCH mapped to raw C++ try/catch (by
defining GDB_XCPT to GDB_XCPT_RAW_TRY in
gdb/common/common-exceptions.h), and that caught a case of code
written between try and catch. This commit fixes it.
gdb/ChangeLog:
2017-10-04 Pedro Alves <palves@redhat.com>
* guile/scm-breakpoint.c (gdbscm_breakpoint_commands): Move code
out of 'between TRY and CATCH'.
While we still have cleanups (i.e., make_cleanup & co), we must be
sure to add END_CATCH at the end of a TRY/CATCH/END_CATCH construct.
However, it's currently too easy to miss adding the END_CATCH, because
the code compiles anyway without it. I realized this when I noticed
that another patch I was working on missed several adding END_CATCH in
several new TRY/CATCH uses.
This commit fixes that by making TRY open a new scope that is only
closed by END_CATCH. This way, if you forget to add the END_CATCH,
then compilation fails due to the unbalanced curly braces.
This caught a couple places where we were missing END_CATCH in current
master, also fixed by the patch.
gdb/ChangeLog:
2017-10-04 Pedro Alves <palves@redhat.com>
* cli/cli-cmds.c (complete_command): Add missing END_CATCH.
* common/common-exceptions.h (TRY): Open an outermost scope.
Expand intro comment.
(CATCH): Reindent.
(END_CATCH): Close the outermost scope.
* completer.c (complete_line_internal): Add missing END_CATCH.
While we still have cleanups (i.e., make_cleanup & co), we must be
sure to add END_CATCH at the end of a TRY/CATCH/END_CATCH construct.
However, it's currently too easy to miss adding the END_CATCH, because
the code compiles anyway without it. I realized this when I noticed
that another patch I was working on missed several adding END_CATCH in
several new TRY/CATCH uses.
This commit fixes that by making TRY open a new scope that is only
closed by END_CATCH. This way, if you forget to add the END_CATCH,
then compilation fails due to the unbalanced curly braces.
This caught a couple places where we were missing END_CATCH in current
master, also fixed by the patch.
gdb/ChangeLog:
2017-10-04 Pedro Alves <palves@redhat.com>
* cli/cli-cmds.c (complete_command): Add missing END_CATCH.
* common/common-exceptions.h (TRY): Open an outermost scope.
Expand intro comment.
(CATCH): Reindent.
(END_CATCH): Close the outermost scope.
* completer.c (complete_line_internal): Add missing END_CATCH.
This is the "natural" extension necessary for the "set cwd" command
(and the whole "set the inferior's cwd" logic) to work on gdbserver.
The idea here is to have a new remote packet, QSetWorkingDir (name
adopted from LLDB's extension to the RSP, as can be seen at
<https://raw.githubusercontent.com/llvm-mirror/lldb/master/docs/lldb-gdb-remote.txt>),
which sends an hex-encoded string representing the working directory
that the remote inferior will use. There is a slight difference from
the packet proposed by LLDB: GDB's version will accept empty
arguments, meaning that the user wants to clear the previously set
working directory for the inferior (i.e., "set cwd" without arguments
on GDB).
For UNIX-like targets this feature is already implemented on
nat/fork-inferior.c, and all gdbserver has to do is to basically
implement "set_inferior_cwd" and call it whenever such packet arrives.
For other targets, like Windows, it is possible to use the existing
"get_inferior_cwd" function and do the necessary steps to make sure
that the inferior will use the specified working directory.
Aside from that, the patch consists basically of updates to the
testcase (making it available on remote targets) and the
documentation.
* NEWS (Changes since GDB 8.0): Add entry about new
'set-cwd-on-gdbserver' feature.
(New remote packets): Add entry for QSetWorkingDir.
* common/common-inferior.h (set_inferior_cwd): New prototype.
* infcmd.c (set_inferior_cwd): Remove "static".
(show_cwd_command): Expand text to include remote debugging.
* remote.c: Add PACKET_QSetWorkingDir.
(remote_protocol_features) <QSetWorkingDir>: New entry for
PACKET_QSetWorkingDir.
(extended_remote_set_inferior_cwd): New function.
(extended_remote_create_inferior): Call
"extended_remote_set_inferior_cwd".
(_initialize_remote): Call "add_packet_config_cmd" for
QSetWorkingDir.
* gdb.texinfo (Starting your Program) <The working directory.>:
Mention remote debugging.
(Working Directory) <Your Program's Working Directory>:
Likewise.
(Connecting) <Remote Packet>: Add "set-working-dir"
and "QSetWorkingDir" to the table.
(Remote Protocol) <QSetWorkingDir>: New item, explaining the
packet.
This commit adds new "set/show cwd" commands, which are used to
set/show the current working directory of the inferior that will be
started.
The idea here is that "set cwd" will become the de facto way of
setting the inferior's cwd. Currently, the user can use "cd" for
that, but there are side effects: with "cd", GDB also switches to
another directory, and that can impact the loading of scripts and
other files. With "set cwd", we separate the logic into a new
command.
To maintain backward compatibility, if the user issues a "cd" command
but doesn't use "set cwd", then the inferior's cwd will still be
changed according to what the user specified. However, "set cwd" has
precedence over "cd", so it can always be used to override it.
"set cwd" works in the following way:
- If the user sets the inferior's cwd by using "set cwd", then this
directory is saved into current_inferior ()->cwd and is used when
the inferior is started (see below).
- If the user doesn't set the inferior's cwd by using "set cwd", but
rather use the "cd" command as before, then this directory is
inherited by the inferior because GDB will have chdir'd into it.
On Unix-like hosts, the way the directory is changed before the
inferior execution is by expanding the user set directory before the
fork, and then "chdir" after the call to fork/vfork on
"fork_inferior", but before the actual execution. On Windows, the
inferior cwd set by the user is passed directly to the CreateProcess
call, which takes care of the actual chdir for us.
This way, we'll make sure that GDB's cwd is not affected by the user
set cwd.
* gdb.texinfo (Starting your Program) <The working directory.>:
Mention new "set cwd" command.
(Working Directory) <Your Program's Working Directory>:
Rephrase to explain that "set cwd" exists and is the default
way to change the inferior's cwd.
Currently, whenever we want to handle paths provided by the user and
perform tilde expansion on GDB, we rely on "tilde_expand", which comes
from readline. This was enough for our use cases so far, but the
situation will change when we start dealing with paths on gdbserver as
well, which is what the next patches implement.
Unfortunately it is not possible to use "tilde_expand" in this case
because gdbserver doesn't use readline. For that reason I decided to
implement a new "gdb_tilde_expand" function, which is basically a
wrapper for "glob" and its GNU extension, GLOB_TILDE_CHECK. With the
import of the "glob" module from gnulib, we're sure that "glob" always
supports this extension.
Passing enum as a first argument to variadic argument function
may lead to undefined behavior. The explanation on CERT site:
https://www.securecoding.cert.org/confluence/display/cplusplus/
EXP58-CPP.+Pass+an+object+of+the+correct+type+to+va_start
The bug was found by Kirill Nedostoev (nedostoev.ka@phystech.edu)
when he tried to build GNU binutils with Clang 7.
PR 22245
* bfd.c (bfd_set_error): Avoid UB on passing arg to va_start that
undergoes default promotion.
* bfd-in2.h: Regenerate.
This removes set_batch_flag_and_make_cleanup_restore_page_info and
make_cleanup_restore_page_info in favor of a new RAII class. This
then allows for the removal of make_cleanup_restore_uinteger and
make_cleanup_restore_integer
Alan Modra [Mon, 2 Oct 2017 22:16:39 +0000 (08:46 +1030)]
ld -z relro documentation
* ld.texinfo (-z relro): Expand description.
(DATA_SEGMENT_ALIGN): Note that -z relro is not effective when
running with system page size larger than commonpagesize.
(DATA_SEGMENT_RELRO_END): Be explicit about the alignment.
Tom Tromey [Mon, 2 Oct 2017 19:55:42 +0000 (13:55 -0600)]
Fix &str printing in Rust
Printing a string slice ("&str") in Rust would print until the
terminating \0; but that is incorrect because a slice has a length.
This fixes &str printing, and arranges to preserve the type name when
slicing a slice, so that printing a slice of an "&str" works as well.
This is PR rust/22236.
2017-10-02 Tom Tromey <tom@tromey.com>
PR rust/22236:
* rust-lang.c (rust_val_print_str): New function.
(val_print_struct): Call it.
(rust_subscript): Preserve name of slice type.
Pedro Alves [Mon, 2 Oct 2017 09:18:30 +0000 (10:18 +0100)]
Fix GDB build with G++ 4.8
G++ 4.8 trips on:
In file included from /opt/gcc-4.8/include/c++/4.8.5/algorithm:62:0,
from ../../src/gdb/ada-lang.c:65:
/opt/gcc-4.8/include/c++/4.8.5/bits/stl_algo.h: In instantiation of ‘_RandomAccessIterator std::__unguarded_partition(_RandomAccessIterator, _RandomAccessIterator, const _Tp&) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<ada_exc_info*, std::vector<ada_exc_info> >; _Tp = ada_exc_info]’:
/opt/gcc-4.8/include/c++/4.8.5/bits/stl_algo.h:2283:70: required from ‘_RandomAccessIterator std::__unguarded_partition_pivot(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<ada_exc_info*, std::vector<ada_exc_info> >]’
/opt/gcc-4.8/include/c++/4.8.5/bits/stl_algo.h:2315:54: required from ‘void std::__introsort_loop(_RandomAccessIterator, _RandomAccessIterator, _Size) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<ada_exc_info*, std::vector<ada_exc_info> >; _Size = long int]’
/opt/gcc-4.8/include/c++/4.8.5/bits/stl_algo.h:5461:36: required from ‘void std::sort(_RAIter, _RAIter) [with _RAIter = __gnu_cxx::__normal_iterator<ada_exc_info*, std::vector<ada_exc_info> >]’
../../src/gdb/ada-lang.c:13153:61: required from here
/opt/gcc-4.8/include/c++/4.8.5/bits/stl_algo.h:2245:19: error: passing ‘const ada_exc_info’ as ‘this’ argument of ‘bool ada_exc_info::operator<(const ada_exc_info&)’ discards qualifiers [-fpermissive]
while (__pivot < *__last)
^
Seems to be a libstdc++ bug meanwhile fixed by:
https://gcc.gnu.org/ml/libstdc++/2012-04/msg00074.
In any case, there's no reason these methods can't be const.
gdb/ChangeLog:
2017-10-02 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* ada-lang.h (ada_exc_info::operator<): Make const.
(ada_exc_info::operator==): Make const.
* ada-lang.c (ada_exc_info::operator<, ada_exc_info::operator==):
Make const.
Simon Marchi [Mon, 2 Oct 2017 09:00:30 +0000 (11:00 +0200)]
nto & lynx x86: call init_target_desc
In gdbserver, target descriptions need to be initialized by calling
init_target_desc. Because i386_create_target_description is shared with
GDB, it doesn't do that, the callers must take care of it. These two
platforms currently don't.
Add new mnemonics for VLE multiple load instructions
opcodes/
* ppc-opc.c (vle_opcodes): Add e_lmvsprw, e_lmvgprw,
e_lmvsrrw, e_lmvcsrrw and e_lmvcsrrw as official mnemonics for
VLE multimple load/store instructions. Old e_ldm* variants are
kept as aliases.
Add missing e_lmvmcsrrw and e_stmvmcsrrw.
gas/
* testsuite/gas/ppc/vle-mult-ld-st-insns.s: New file: Tests the
support for the VLE multiple load/store instructions.
* testsuite/gas/ppc/vle-mult-ld-st-insns.d: New file: Test
driver.
* testsuite/gas/ppc/ppc.exp: Run it.
Alan Modra [Sun, 1 Oct 2017 01:37:59 +0000 (12:07 +1030)]
PR22047, Heap out of bounds read in parse_comp_unit
Like the PR22230 fix, we can allocate a buffer with an extra byte
rather than letting bfd_simple_get_relocated_section_contents malloc
and return a buffer. Much better than allocating another buffer
afterwards.
PR 22047
* dwarf2.c (read_section): Allocate buffer with extra byte for
bfd_simple_get_relocated_section_contents rather than copying
afterwards.
Tom Tromey [Sat, 23 Sep 2017 17:21:58 +0000 (11:21 -0600)]
Remove free_memory_read_result_vector
This changes read_memory_robust to return a std::vector, allowing the
removal of free_memory_read_result_vector and associated cleanups.
This patch also changes the functions it touches to be a bit more
robust with regards to deallocation; it's perhaps possible that
read_memory_robust could have leaked in some situations.
This patch is based on my earlier series to remove some MI cleanups.
Regression tested by the buildbot.
gdb/ChangeLog
2017-09-29 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 5 May 2017 03:25:55 +0000 (21:25 -0600)]
Change captured_mi_execute_command to use scoped_restore
Change captured_mi_execute_command to use a scoped_restore, removing a
cleanup. The old code copied the current token, but I don't believe
that is necessary.
gdb/ChangeLog
2017-09-29 Tom Tromey <tom@tromey.com>
* mi/mi-main.c (captured_mi_execute_command): Use scope_restore.
Tom Tromey [Wed, 3 May 2017 23:26:47 +0000 (17:26 -0600)]
Remove cleanups from mi-cmd-var.c
This removes some cleanups from mi-cmd-var.c. varobj_gen_name now
returns a string, simplifying mi_cmd_var_create. In
mi_cmd_var_delete, a string copy is apparently unnecessary, so it's
simply removed.
gdb/ChangeLog
2017-09-29 Tom Tromey <tom@tromey.com>
Tom Tromey [Thu, 28 Sep 2017 02:42:21 +0000 (20:42 -0600)]
Remove some cleanups from stack.c
This removes some cleanups from stack.c by using std::string or
gdb::unique_xmalloc_ptr. One cleanup remains in this file; I did not
remove it here because it is handled in another patch series that has
yet to be resolved.
gdb/ChangeLog
2017-09-29 Tom Tromey <tom@tromey.com>
* stack.c (parse_frame_specification): Use std::string
(info_frame_command): Use gdb::unique_xmalloc_ptr.
Pedro Alves [Fri, 29 Sep 2017 16:15:36 +0000 (17:15 +0100)]
Constify unpack_varlen_hex & fix fallout
I ran into non-const unpack_varlen_hex while working on something
else, and decided to just fix it first. Ends up constifying a good
deal of remote packet parsing.
gdb/ChangeLog:
2017-09-29 Pedro Alves <palves@redhat.com>
This finally eliminates an old hack left in place when tracepoint RSP
support was migrated from tracepoint.c to remote.c, back in 35b1e5cca081 ("Make tracepoint operations go through target vector.")
over 7 years ago.
Tested on x86_64 GNU/Linux.
gdb/ChangeLog:
2017-09-29 Pedro Alves <palves@redhat.com>
* remote.c (target_buf, target_buf_size): Delete.
(remote_get_noisy_reply): Remove buf_p and sizeof_buf parameters.
Use the connection's packet buffer instead.
All callers adjusted.
(_initialize_remote): Remove references to target_buf and
target_buf_size.
Pedro Alves [Fri, 29 Sep 2017 12:06:34 +0000 (13:06 +0100)]
Fix gdbserver regression exposed by gdb.threads/multi-create-ns-info-thr.exp
Commit 8629910955a7 ("Add thread_db_notice_clone to gdbserver")
introduced calls into libthread_db without making sure that the
current thread is pointing to a know-stopped thread. This resulted in
sometimes thread_db_notice_clone failing->find_one_thread failing like
this, as seen when running gdb.threads/multi-create-ns-info-thr.exp:
Things go south from here and sometimes that ends up resulting in
gdbserver crashing and the test failing.
gdb/gdbserver/ChangeLog:
2017-09-29 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Pass parent thread instead
of process to thread_db_notice_clone.
* linux-low.h (thread_db_notice_clone): Replace parent process
parameter with parent thread parameter.
* thread-db.c (find_one_thread): Add comment.
(thread_db_notice_clone): Replace parent process parameter with
parent thread parameter. Temporarily switch to the parent thread.
Alan Modra [Fri, 29 Sep 2017 03:37:56 +0000 (13:07 +0930)]
Fail when string merge can't alloc memory
I was looking at Debian bug #874674 again today, and think I might
have spotted the problem. It appears that merge.c tries to cope with
memory allocation failures in some circumstances, but doesn't quite
manage to get everything right. This patch will make ld report memory
allocation failures instead of silently not merging strings.
* merge.c (merge_strings): Return FALSE on malloc failure.
(_bfd_merge_sections): Return failures from record_section and
merge_strings.
Nick Clifton [Thu, 28 Sep 2017 10:33:20 +0000 (11:33 +0100)]
Skip the PR 14918 linker test for ARM targets.
I am applying a patch that has been lying around in the Fedora
binutils sources for a while. It skips the PR14918 linker test for
ARM based targets. This test checks that libgcc is not included in a
link of an empty executable. This works for most targets, but on the
ARM the crt1.o startup code calls __libc_csu_init which is in
/usr/lib/libc_nonshared.a(elf-init.oS). This in turn needs
__aeabi_unwind_cpp_pr0@@GCC_3.5 which is provided by libgcc_s.so.1,
and so the test fails.
Alan Modra [Thu, 28 Sep 2017 07:41:38 +0000 (17:11 +0930)]
PR22220, BFD linker wrongly marks symbols as PREVAILING_DEF_IRONLY
non_ir_ref_dynamic wasn't being set in the case where we have a
versioned dynamic symbol definition with a non-versioned matching IR
symbol.
bfd/
PR 22220
* elflink.c (_bfd_elf_merge_symbol): Set non_ir_ref_dynamic in
a case where plugin_notice isn't called.
ld/
* testsuite/ld-plugin/pr22220.h,
* testsuite/ld-plugin/pr22220lib.cc,
* testsuite/ld-plugin/pr22220lib.ver,
* testsuite/ld-plugin/pr22220main.cc: New test.
* testsuite/ld-plugin/lto.exp: Run it.
Many tdep files need to perform conversions between two floating-point
types, usually when accessing FP registers. Most targets now use the
convert_typed_floating helper routine to do so. However, a small number
still use the old method of converting via a DOUBLEST. Since we want
to get rid of DOUBLEST, these targets need to be moved to the new
method as well.
The main obstacle is that for convert_typed_floating we need an actual
*type*, not just a floatformat.
In arm-tdep.c, this is very straightforward, since there is already a
type using the ARM extended floatformat.
For sh-tdep.c and sh64-tdep.c, no such type already exists, so I've
added one to the gdbarch_tdep struct as done on other targets.
For historical reasons, the TYPE_FLOATFORMAT element is still set to hold
an array of two floatformat structs, one for big-endian and the other for
little-endian. When accessing the element via floatformat_from_type,
the code would check the type's byte order and return the appropriate
floatformat.
However, these days this is quite unnecessary, since the type's byte order
is already known at the time the type is allocated and the floatformat is
installed into TYPE_FLOATFORMAT. Therefore, we can just install the correct
version here.
Also, moves the (now trivially simple) floatformat_from_type accessor to
gdbtypes.{c,h}, since it doesn't really need to be in doublest.c now.
* doublest.h (floatformat_from_type): Move to gdbtypes.h.
* doublest.c (floatformat_from_type): Move to gdbtypes.c.
* gdbtypes.h (union type_specific): Make field floatformat hold
just a single struct floatformat, not an array.
(floatformat_from_type): Move here.
* gdbtypes.c (floatformat_from_type): Move here. Update to
changed TYPE_FLOATFORMAT definition.
(verify_floatformat): Update to changed TYPE_FLOATFORMAT.
(recursive_dump_type): Likewise.
(init_float_type): Install correct floatformat for byte order.
(arch_float_type): Likewise.
This changes the interfaces to init_type and arch_type to take the
type length in bits as input (instead of as bytes). The routines
assert that the length is a multiple of TARGET_CHAR_BIT.
For consistency, arch_flags_type is changed likewise, so that now
all type creation interfaces always use length in bits.
All callers are updated in the straightforward manner.
The assert actually found a bug in read_range_type, where the
init_integer_type routine was called with a wrong argument (probably
a bug introduced with the conversion to use init_integer_type).
Nick Clifton [Wed, 27 Sep 2017 15:21:36 +0000 (16:21 +0100)]
Add support for the new names of the RISC-V fmv.x.s and fmv.s.x instructions, vis: fmv.x.w and fmv.w.x.
PR 22179
opcodes * riscv-opc.c (riscv_opcodes): Add fmv.x.w and fmv.w.x as the new
names for the fmv.x.s and fmv.s.x instructions respectively.
gas * testsuite/gas/riscv/fmv.x.s: New file: Tests the support for the
renamed fmv.x.s and fmv.s.x instructions.
* testsuite/gas/riscv/fmv.x.d: New file: Test driver.
projects / thirdparty / binutils-gdb.git / log
