PR 19405
* elf32-nios2.c (nios2_elf32_install_imm16): Allow for signed
immediate values.
* elf-eh-frame.c (_bfd_elf_discard_section_eh_frame): Limit the
number of messages about FDE encoding preventing .eh_frame_hdr
generation.
Now that the GDB 7.11 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 7.11 branch created (9ef9e6a6a0):
* version.in: Bump version to 7.11.50.DATE-git.
One of the last checks update_breakpoints_after_exec does while looping
over the list of breakpoints is check that the breakpoint has a valid
location spec. It uses event_location_empty_p to check if the location spec
is "empty", and if it is, the breakpoint is deleted.
momentary_breakpoint types rely on setting the breakpoint structure's
location spec to NULL, thereby causing an update to delete the breakpoint.
However, event_location_empty_p assumed that locations were never NULL.
As a result, GDB would crash dereferencing a NULL pointer whenever
update_breakpoints_after_exec would encounter a momentary_breakpoint.
This patch creates a new wrapper/helper function which tests that the given
breakpoint's location spec is non-NULL and if it is not "empty"
or "unspecified."
gdb/ChangeLog
PR breakpoints/19546
* breakpoint.c (breakpoint_event_location_empty_p): New function.
(update_breakpoints_after_exec, bkpt_re_set): Use this new function
instead of event_location_empty_p.
gdb/testsuite/ChangeLog
PR breakpoints/19546
* gdb.base/infcall-exec.c: New file.
* gdb.base/infcall-exec2.c: New file.
* gdb.base/infcall-exec.exp: New file.
MI is currently using string_to_event_location to enable the use of legacy
linespecs, but using this function (until this patchset) had the (as yet
unnoticed) side effect of allowing both MI and CLI representation for
explicit locations.
This patch simply changes MI to use the same legacy linespec functions
that the python and guile interpreters use. This eliminates the CLI syntax
for explicit locations (in MI).
gdb/ChangeLog
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Use
string_to_event_location_basic instead of string_to_event_location.
This patch, analogous to the previous python patch, implements proper
legacy linespec support in guile code using the newly introduced
string_to_event_location_basic.
gdb/ChangeLog
* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Skip
leading whitespace and use string_to_event_location_basic instead
of new_linespec_location.
gdb/testsuite/ChangeLog
* gdb.guile/scm-breakpoint.exp (test_bkpt_address): New procedure.
(toplevel): Call test_bkpt_address.
Now that "legacy" linespecs benefit from consolidated support in
string_to_event_location_basic, python's Breakpoint command should use this
function to turn strings into event locations.
As a result, this patch fixes python/19506. Before:
(gdb) python gdb.Breakpoint("*main")
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Function "*main" not defined.
Error while executing Python code.
After:
(gdb) python gdb.Breakpoint("*main")
Breakpoint 1 at 0x4005fb: file ../../../src/gdb/testsuite/gdb.python/py-breakpoint.c, line 32.
gdb/ChangeLog
PR python/19506
* python/py-breakpoint.c (bppy_init): Use
string_to_event_location_basic instead of new_linespec_location.
gdb/testsuite/ChangeLog
PR python/19506
* gdb.python/py-breakpoint.exp (test_bkpt_address): New procedure.
(toplevel): Call test_bkpt_address.
This patch refactors string_to_event_location, breaking it into two
separate functions:
1) string_to_event_location_basic
A "basic" string parser that implements support for "legacy" linespecs
(linespec, address, and probe locations). This function is intended to
be used by any UI wishing/needing to support this legacy behavior.
2) string_to_event_location
This is now intended as a CLI-only function which adds explicit location
parsing in a CLI-appropriate manner (in the form of traditional option/value
pairs).
Together these patches serve to simplify string-to-event location parsing
for all existing non-CLI interfaces (MI, guile, and python).
gdb/ChangeLog
* location.c (string_to_explicit_location): Note that "-p" is
reserved for probe locations and return NULL for any input
that starts with that.
(string_to_event_location): Move "legacy" linespec code to ...
(string_to_event_location_basic): ... here.
* location.h (string_to_event_location): Update comment.
(string_to_event_location_basic): New function.
Using AC_OUTPUT with arguments has been deprecated for some time in
autoconf, even in version 2.64, which we are using. This change should
not affect functionality.
I also removed the "exit 0"'s, they shouldn't be necessary.
gdb/ChangeLog:
* configure.ac: Use AC_CONFIG_FILES instead of passing arguments
to AC_OUTPUT. Remove "exit 0" at the end.
* configure: Regenerate.
gdb/testsuite/ChangeLog:
* configure.ac: Use AC_CONFIG_FILES instead of passing arguments
to AC_OUTPUT.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
* configure.ac: Use AC_CONFIG_FILES instead of passing arguments
to AC_OUTPUT.
* configure: Regenerate.
PR19548 shows that we still have problems related to 13fd3ff343:
[PR17431: following execs with "breakpoint always-inserted on"]
https://sourceware.org/ml/gdb-patches/2014-09/msg00733.html
The problem this time is that we currently update the global location
list and try to insert breakpoint locations after re-setting _each_
breakpoint in turn.
Say:
- We have _more_ than one breakpoint set. Let's assume 2.
- There's a breakpoint with a pre-exec address that ends up being an
unmapped address after the exec.
- That breakpoint is NOT the first in the breakpoint list.
Then when handling an exec, and we re-set the first breakpoint in the
breakpoint list, we mistakently try to install the old pre-exec /
un-re-set locations of the other breakpoint, which fails:
(gdb) continue
Continuing.
process 28295 is executing new program: (...)/execl-update-breakpoints2
Error in re-setting breakpoint 1: Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0x1000764
Breakpoint 1, main (argc=1, argv=0x7fffffffd368) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/execl-update-breakpoints.c:34
34 len = strlen (argv[0]);
(gdb)
Fix this by deferring the global location list update till after all
breakpoints are re-set.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog:
2016-02-09 Pedro Alves <palves@redhat.com>
PR breakpoints/19548
* breakpoint.c (create_overlay_event_breakpoint): Don't update
global location list here.
(create_longjmp_master_breakpoint)
(create_std_terminate_master_breakpoint)
(create_exception_master_breakpoint, create_jit_event_breakpoint)
(update_breakpoint_locations):
(breakpoint_re_set): Update global location list after all
breakpoints are re-set.
gdb/testsuite/ChangeLog:
2016-02-09 Pedro Alves <palves@redhat.com>
PR breakpoints/19548
* gdb.base/execl-update-breakpoints.c (some_function): New
function.
(main): Call it.
* gdb.base/execl-update-breakpoints.exp: Add a second breakpoint.
Tighten expected GDB output.
Change the signature of gdbserver's siginfo_fixup functions so that it's
in line with gdb's. This gets rid of the following build error in C++:
/home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c: In function ‘int x86_siginfo_fixup(siginfo_t*, void*, int)’:
/home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:694:21: error: invalid conversion from ‘void*’ to ‘gdb_byte* {aka unsigned char*}’ [-fpermissive]
FIXUP_32);
^
In file included from /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:31:0:
/home/emaisin/src/binutils-gdb/gdb/gdbserver/../nat/amd64-linux-siginfo.h:52:5: error: initializing argument 2 of ‘int amd64_linux_siginfo_fixup_common(siginfo_t*, gdb_byte*, int, amd64_siginfo_fixup_mode)’ [-fpermissive]
int amd64_linux_siginfo_fixup_common (siginfo_t *native, gdb_byte *inf,
^
/home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:698:20: error: invalid conversion from ‘void*’ to ‘gdb_byte* {aka unsigned char*}’ [-fpermissive]
FIXUP_X32);
^
In file included from /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:31:0:
/home/emaisin/src/binutils-gdb/gdb/gdbserver/../nat/amd64-linux-siginfo.h:52:5: error: initializing argument 2 of ‘int amd64_linux_siginfo_fixup_common(siginfo_t*, gdb_byte*, int, amd64_siginfo_fixup_mode)’ [-fpermissive]
int amd64_linux_siginfo_fixup_common (siginfo_t *native, gdb_byte *inf,
^
gdb/gdbserver/ChangeLog:
* linux-aarch64-low.c (aarch64_linux_siginfo_fixup): Change
void * to gdb_byte *.
* linux-low.c (siginfo_fixup): Likewise.
(linux_xfer_siginfo): Likewise.
* linux-low.h (struct linux_target_ops) <siginfo_fixup>:
Likewise.
* linux-x86-low.c (x86_siginfo_fixup): Likewise.
bfd * elfnn-aarch64.c (elfNN_aarch64_relocate_section): Add a more
helpful warning message to explain why certain AArch64 relocs
might overflow.
ld * testsuite/ld-aarch64/reloc-overflow-bad.d: New test.
* testsuite/ld-aarch64/reloc-overflow-1.s: New source file.
* testsuite/ld-aarch64/reloc-overflow-2.s: New source file.
* testsuite/ld-aarch64/aarch64-elf.exp: Run the new test.
Add a cast to reinterpret a void* as a gdb_byte*.
2016-02-09 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (x86_siginfo_fixup): Add cast to gdb_byte*.
bfd * elfnn-aarch64.c (elfNN_aarch64_relocate_section): Add a more
helpful warning message to explain why certain AArch64 relocs
might overflow.
ld * testsuite/ld-aarch64/reloc-overflow-bad.d: New test.
* testsuite/ld-aarch64/reloc-overflow-1.s: New source file.
* testsuite/ld-aarch64/reloc-overflow-2.s: New source file.
* testsuite/ld-aarch64/aarch64-elf.exp: Run the new test.
When running tests in parallel, each test puts its generated files in a
different directory, under "outputs". I think it would be nice if it
was always the case, as it would isolate the test cases a bit more. An
artifact created by a test wouldn't get overwritten by another test.
Also, it makes it easier to clean up. A lot of executables are left all
over the place because their names do not appear in gdb.*/Makefile. If
everything is in "outputs", then we just have to delete that directory
(which we already do).
At the same time it makes the gdb.foo directories and their Makefiles
useless in the build directory, since they are pretty much only used for
cleaning.
What do you think?
gdb/testsuite/ChangeLog:
* Makefile.in (ALL_SUBDIRS): Remove.
(clean mostlyclean): Do not recurse in ALL_SUBDIRS.
(distclean maintainer-clean realclean): Likewise.
* configure.ac (AC_OUTPUT): Remove gdb.*/Makefile.
* configure: Regenerate.
* gdb.ada/Makefile.in: Delete.
* gdb.arch/Makefile.in: Likewise.
* gdb.asm/Makefile.in: Likewise.
* gdb.base/Makefile.in: Likewise.
* gdb.btrace/Makefile.in: Likewise.
* gdb.cell/Makefile.in: Likewise.
* gdb.compile/Makefile.in: Likewise.
* gdb.cp/Makefile.in: Likewise.
* gdb.disasm/Makefile.in: Likewise.
* gdb.dlang/Makefile.in: Likewise.
* gdb.dwarf2/Makefile.in: Likewise.
* gdb.fortran/Makefile.in: Likewise.
* gdb.gdb/Makefile.in: Likewise.
* gdb.go/Makefile.in: Likewise.
* gdb.guile/Makefile.in: Likewise.
* gdb.java/Makefile.in: Likewise.
* gdb.linespec/Makefile.in: Likewise.
* gdb.mi/Makefile.in: Likewise.
* gdb.modula2/Makefile.in: Likewise.
* gdb.multi/Makefile.in: Likewise.
* gdb.objc/Makefile.in: Likewise.
* gdb.opencl/Makefile.in: Likewise.
* gdb.opt/Makefile.in: Likewise.
* gdb.pascal/Makefile.in: Likewise.
* gdb.perf/Makefile.in: Likewise.
* gdb.python/Makefile.in: Likewise.
* gdb.reverse/Makefile.in: Likewise.
* gdb.server/Makefile.in: Likewise.
* gdb.stabs/Makefile.in: Likewise.
* gdb.threads/Makefile.in: Likewise.
* gdb.trace/Makefile.in: Likewise.
* gdb.xml/Makefile.in: Likewise.
* lib/gdb.exp (make_gdb_parallel_path): Add check for
GDB_PARALLEL.
(standard_output_file): Remove check for GDB_PARALLEL, always
return path in outputs/$subdir/$testname.
While testing the following patch,
[PATCH] Always organize test artifacts in a directory hierarchy
https://sourceware.org/ml/gdb-patches/2016-01/msg00133.html
I noticed that it broke Ada testing. This lead me to think that
parallel testing when building in-tree didn't work previously in Ada.
It is confirmed by this test:
$ make check TESTS="gdb.ada/fun_addr.exp" -j 2
...
Running ./gdb.ada/fun_addr.exp ...
FAIL: gdb.ada/fun_addr.exp: compilation foo.adb
...
This patch fixes in-tree parallel testing for Ada, and consequently
serial and parallel testing when the aforementioned patch is applied.
The problem originates from the fact that Ada support code cd's to the
builddir before compiling. In itself it's not a problem, it allows to
place intermediate auto-generated files in that directory. The Ada
compilation refers to the source file, which is in another directory,
only by its base name (e.g. foo.adb). In serial mode, that worked
because builddir was the same as the source directory (e.g.
gdb.ada/fun_addr/). In an out-of-tree build, it works because the
source directory is added as an include directory (note: this is not the
same $srcdir as autoconf's):
set srcdir [file dirname $source]
additional_flags=-I$srcdir
which becomes:
additional_flags=-I/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.ada/fun_addr
However, when building in-tree, srcdir is relative: ./gdb.ada/fun_addr.
When using parallel or always-in-outputs-directory mode, we are cd'ed in
the outputs directory. So -I$srcdir is relative to the current
directory, which is wrong.
To fix it, I made the TCL variable srcdir (set in site.exp, from which
everything else is derived) always absolute. It is done by assigning
autoconf's abs_srcdir instead of autoconf's srcdir. This way -I$srcdir
will always be good, regardless of where we cd'ed to. A small apparent
change is that when running tests, DejaGnu will say:
Running /tmp/binutils-gdb/gdb/testsuite/gdb.ada/fun_addr.exp ...
instead of
Running ./gdb.ada/fun_addr.exp ...
I hope it's not too much of an annoyance. I think that it should make
the testsuite a tiny bit more robust against other bugs of the same
class.
Regtested in & out of tree, only with native target.
gdb/testsuite/ChangeLog:
* Makefile.in (abs_srcdir): Assign @abs_srcdir@.
(site.exp): Assign abs_srcdir to tcl's srcdir.
I built remote.c with -Wunused, to check a function I was working on,
turns out there is a bunch of unused variables.
gdb/ChangeLog:
* remote.c (remote_register_number_and_offset): Remove unused
variable(s).
(remote_thread_always_alive): Likewise.
(remote_update_thread_list): Likewise.
(process_initial_stop_replies): Likewise.
(remote_start_remote): Likewise.
(remote_check_symbols): Likewise.
(discard_pending_stop_replies): Likewise.
(process_stop_reply): Likewise.
(putpkt_binary): Likewise.
(getpkt): Likewise.
(remote_add_target_side_condition): Likewise.
(remote_insert_breakpoint): Likewise.
(remote_supports_stopped_by_sw_breakpoint): Likewise.
(remote_supports_stopped_by_hw_breakpoint): Likewise.
(remote_xfer_partial): Likewise.
(remote_read_btrace): Likewise.
(remote_async_serial_handler): Likewise.
(remote_thread_events): Likewise.
(_initialize_remote): Likewise.
On x32, a pc-relative reference to an undef weak symbol (value 0)
with a negative addend (typically -4) generates a spurious overflow
error because Symbol_value::value() returns a 32-bit negative number
as an unsigned number, which gets zero-extended before subtracting
the PC value. This patch fixes the problem by special-casing the
negative addend, and adding it to the value after widening it to
64 bits. Symbol_value::value() does not need the addend if it's
negative, since it is only important when processing section
symbols for merge sections, where a positive addend provides the
input section offset of the merged constant.
gold/
* x86_64.cc (X86_64_relocate_functions::pcrela32_check): Fix x32
overflow checking when symbol value + addend < 0.
This patch removes some dead code.
I noticed that varobj_delete was always called with dellist == NULL, so
I started removing that parameter. That allows removing a good chunk of
the code in varobj_delete, making it almost trivial. We can also remove
the resultp parameters in that whole trail. In turn, this shows that
struct cpstack, cppush and cppop were only used fo that mechanism, so
they can be removed as well.
I also moved the function comment to the header file to comply with
today's guideline, even though the rest of the file does not respect it
(yet).
gdb/ChangeLog:
* varobj.h (varobj_delete): Remove dellist parameter, update and
move documentation here.
* varobj.c (struct cpstack, cppush, cppop): Remove.
(delete_variable): Remove resultp (first) parameter.
(delete_variable_1): Likewise.
(varobj_delete): Remove dellist parameter and unused code.
(update_dynamic_varobj_children): Adjust varobj_delete call.
(update_type_if_necessary): Likewise.
(varobj_set_visualizer): Likewise.
(varobj_update): Likewise.
(value_of_root): Likewise.
(varobj_invalidate_iter): Likewise.
* mi/mi-cmd-var.c (mi_cmd_var_delete): Likewise.
In order to get around the optimizer and newer compiler warnings
about shift counts, the overflow checking code had resorted to
some messy shifting, and with the never-before-seen instantiations
of the template functions, we were still running afoul of the
compiler checks.
This patch replaces those messy shift sequences with a simple
class template that provides the min and max limits for any
bit size up to 64, with a specialization for 64 that prevents
the compiler from complaining.
gold/
PR gold/19577
* reloc.h (Limits): New class.
(Bits::has_overflow32): Use min/max values from Limits.
(Bits::has_unsigned_overflow32): Likewise.
(Bits::has_signed_unsigned_overflow32): Likewise.
(Bits::has_overflow): Likewise.
(Bits::has_unsigned_overflow): Likewise.
(Bits::has_signed_unsigned_overflow64): Likewise.
The problem here is that x32 is really using 64-bit addressing,
while pretending to be 32-bit. Even though the object file format
is 32-bit, we need to do the overflow checking with 64-bit
arithmetic (because that's what the hardware will be using).
This patch overrides the pcrela32_check functions in reloc.h
with target-specific versions that do 64-bit checking.
I've also updated the test case to use -Tdata instead of adding
a huge .space directive, to reduce the size of the .o files.
gold/
PR gold/19567
* reloc.h (Relocate_functions::Overflow_check): Add comments.
* x86_64.cc (X86_64_relocate_functions): New class.
(Target_x86_64::Relocate::relocate): Use the new class.
* testsuite/Makefile.am (x86_64_overflow_pc32): Add -Tdata option.
(x32_overflow_pc32): New test case.
* testsuite/Makefile.in: Regenerate.
* testsuite/x32_overflow_pc32.sh: New script.
* testsuite/x86_64_overflow_pc32.s: Remove .space directive.
This is needed by s390 split-stack support, to distinguish call
and load-address relocations.
gold/ChangeLog:
* i386.cc (Target_i386::is_call_to_non_split): Add view and view_size
parameters.
* reloc.cc (Sized_relobj_file::split_stack_adjust_reltype): Pass view
and view_size to is_call_to_non_split.
* target.cc (Target::is_call_to_non_split): Add view and view_size
parameters.
* target.h (class Target): Likewise.
* icf.cc (get_rel_addend): New function.
(get_section_contents): Move merge section addend computation to a
new function. Ignore negative values for SHT_REL and SHT_RELA addends.
Fix bug to not read past the length of the section.
Fix bug related to addend computation for MERGE sections.
* cgen-scache.c (scache_option_handler): Prevent possible
undefined behaviour computing the size of the scache by using
unsigned integers instead of signed integers.
BASEDIR was added by https://sourceware.org/ml/gdb-patches/2013-10/msg00587.html
in order to handle the different directory layout in serial testing
and parallel testing. BASEDIR is "gdb.base" in serial testing and is
"outputs/gdb.base/TESTNAME" in parallel testing. However, it doesn't
work if the GDBserver is in remote target, like this,
$ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost foll-vfork.exp foll-exec.exp'
FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program exited)
FAIL: gdb.base/foll-vfork.exp: exec: vfork and exec child follow, to main bp: continue to bp (the program exited)
FAIL: gdb.base/foll-vfork.exp: exec: vfork child follow, finish after tcatch vfork: finish (the program exited)
FAIL: gdb.base/foll-vfork.exp: exec: vfork relations in info inferiors: continue to bp (the program exited)
these tests fail because the executable can't be found. With target
board native-gdbserver, the program is spawned this way,
spawn ../gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork
so BASEDIR is correct. However, with target board
remote-gdbserver-on-localhost, the program is spawned
spawn /usr/bin/ssh -l yao localhost /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork
so BASEDIR (either "gdb.base" or "outputs/gdb.base/TESTNAME") makes no
sense.
I had a fix that pass absolute directory to BASEDIR, but it assumes
that directory structure is the same on build and target, and it
doesn't work in remote host case. The current fix in this patch is
to get the directory from argv[0]. In any case, the program to be
exec'ed is at the same directory with the main program.
Note that these tests do "next N" to let program stop at the desired
line, but it is fragile, because GDB for different targets may skip
function prologue slightly differently, so I replace some of them by
"tbreak on LINE NUMBER and continue".
gdb/testsuite:
2016-02-04 Yao Qi <yao.qi@linaro.org>
* gdb.base/foll-exec-mode.c: Include limits.h.
(main): Add parameters argc and argv. Get directory from
argv[0].
* gdb.base/foll-exec-mode.exp: Don't pass -DBASEDIR in
compilation.
* gdb.base/foll-exec.c: Include limits.h.
(main): Add parameters argc and argv.
Get directory from argv[0].
* gdb.base/foll-exec.exp: Don't pass -DBASEDIR in compilation.
Adjust tests on the number of lines as source code changed.
* gdb.base/foll-vfork-exit.c: Include limits.h.
(main): Add one line of statement before vfork.
* gdb.base/foll-vfork.c: Include limits.h and string.h.
(main): Add parameters argc and argv. Get directory from
argv[0].
* gdb.base/foll-vfork.exp: Don't pass -DBASEDIR in compilation.
(setup_gdb): Set tbreak to skip some source lines.
* gdb.multi/bkpt-multi-exec.c: Include limits.h.
(main): Add parameters argc and argv. Get directory from
argv[0].
* gdb.multi/bkpt-multi-exec.exp: Don't pass -DBASEDIR in
compilation.
* gdb.multi/multi-arch-exec.c: Include limits.h and string.h.
(main): Add parameters argc and argv. Get directory from
argv[0].
* gdb.multi/multi-arch-exec.exp: Don't pass -DBASEDIR in
compilation.
Hi,
I see this error when GDB connects with qemu,
(gdb) n
....
Sending packet: $vCont;c#a8...Ack
Packet received: Ffstat,00000001,f6fff038
Cannot execute this command while the target is running.
Use the "interrupt" command to stop the target
and then try again.
looks we don't set rs->waiting_for_stop_reply to zero
before handle fileio request,
#10 0x00000000005edb64 in target_write (len=64, offset=4143968312, buf=0x7fffffffd570 "\375\377\377\377", annex=0x0, object=TARGET_OBJECT_MEMORY,
ops=<optimised out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1922
#11 target_write_memory (memaddr=memaddr@entry=4143968312, myaddr=myaddr@entry=0x7fffffffd6a0 "", len=len@entry=64)
at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1500
#12 0x00000000004b2b41 in remote_fileio_func_fstat (buf=0x127b258 "") at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1037
#13 0x00000000004b1878 in do_remote_fileio_request (uiout=<optimised out>, buf_arg=buf_arg@entry=0x127b240)
at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1204
#14 0x00000000005b8c7c in catch_exceptions_with_msg (func_uiout=<optimised out>, func=func@entry=0x4b1800 <do_remote_fileio_request>,
func_args=func_args@entry=0x127b240, gdberrmsg=gdberrmsg@entry=0x0, mask=mask@entry=RETURN_MASK_ALL)
at /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:187
#15 0x00000000005b8dea in catch_exceptions (uiout=<optimised out>, func=func@entry=0x4b1800 <do_remote_fileio_request>, func_args=func_args@entry=0x127b240,
mask=mask@entry=RETURN_MASK_ALL) at /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:167
#16 0x00000000004b2fff in remote_fileio_request (buf=0x127b240 "Xf6fff038,0:", ctrlc_pending_p=0) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1255
#17 0x0000000000496f12 in remote_wait_as (ptid=..., status=0x7fffffffdb20, options=1) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:6997
however, we did set rs->waiting_for_stop_reply to zero before Luis's
patch https://sourceware.org/ml/gdb-patches/2015-10/msg00336.html
In fact, Luis's patch v1
https://sourceware.org/ml/gdb-patches/2015-08/msg00809.html is about
setting rs->waiting_for_stop_reply back to one after
remote_fileio_request, which is correct. However during the review, the
patch is changed and ends up with "not setting rs->waiting_for_stop_reply
to zero".
I manually test GDB, but I don't have a way to run regression tests.
gdb:
2016-02-04 Yao Qi <yao.qi@linaro.org>
* remote.c (remote_wait_as): Set rs->waiting_for_stop_reply to
0 before handling 'F' and set it back afterwards.
PR target/19561
opcdoe * msp430-dis.c (print_insn_msp430): Add a special case for
decoding an RRC instruction with the ZC bit set in the extension
word.
include * opcode/msp430.h (IGNORE_CARRY_BIT): New define.
(RRUX): Synthesise using case 2 rather than 7.
gas * config/tc-msp430.c (msp430_operands): Remove case 7. Use case 2
to handle encoding of RRUX instruction.
* testsuite/gas/msp430/msp430x.s: Add more tests of the extended
shift instructions.
* testsuite/gas/msp430/msp430x.d: Update expected disassembly.
