* elf32-i386.c (elf_i386_convert_load): Extract the GOT load
conversion to ...
(elf_i386_convert_load_reloc): This. New function.
* elf64-x86-64.c (elf_x86_64_convert_load): Extract the GOT load
conversion to ...
(elf_x86_64_convert_load_reloc): This. New function.
Cache the section contents in x86 check_relocs for sections without
TLS relocations.
* elf32-i386.c (elf_i386_check_tls_transition): Remove abfd.
Don't check if contents == NULL.
(elf_i386_tls_transition): Add from_relocate_section. Check
from_relocate_section instead of contents != NULL. Update
elf_i386_check_tls_transition call.
(elf_i386_check_relocs): Cache the section contents if
keep_memory is FALSE. Pass FALSE as from_relocate_section to
elf_i386_tls_transition.
(elf_i386_relocate_section): Pass TRUE as from_relocate_section
to elf_i386_tls_transition.
(elf_backend_caches_rawsize): New.
* elf64-x86-64.c (elf_x86_64_check_tls_transition): Don't check
if contents == NULL.
(elf_x86_64_tls_transition): Add from_relocate_section. Check
from_relocate_section instead of contents != NULL.
(elf_x86_64_check_relocs): Cache the section contents if
keep_memory is FALSE. Pass FALSE as from_relocate_section to
elf_x86_64_tls_transition.
(elf_x86_64_relocate_section): Pass TRUE as from_relocate_section
to elf_x86_64_tls_transition.
(elf_backend_caches_rawsize): New.
This patch initialize res to zero, otherwise, it may have some garbage
bits after the *the_target->read_memory call.
gdb/gdbserver:
2016-05-05 Yao Qi <yao.qi@linaro.org>
* linux-arm-low.c (get_next_pcs_read_memory_unsigned_integer):
Initialize res to zero.
Variable cpsr holds the value of cpsr register, which is 32-bit. It
is better to explicitly use uint32_t.
gdb/gdbserver:
2016-05-05 Yao Qi <yao.qi@linaro.org>
* linux-arm-low.c (arm_sigreturn_next_pc): Change type of cpsr
to uint32_t.
ChangeLog:
* spu-linux-nat.c (spu_bfd_iovec_pread): Add pointer cast for C++.
(spu_bfd_open): Likewise.
gdbserver/ChangeLog:
* spu-low.c (fetch_ppc_register): Cast PowerPC-Linux-specific value
used as first ptrace argument to PTRACE_TYPE_ARG1 for C++.
(fetch_ppc_memory_1, store_ppc_memory_1): Likewise.
Some targets are only really, or at least regularly, regression-tested
in a crossed configuration. Currently we only have native compiled test
cases for the STB_GNU_UNIQUE feature in the linker test suite. This is
nice, covering run-time semantics even, but quite often not run at all.
Consequently a regression may remain unnoticed for long.
Add a simple test case then to provide basic linker coverage with no
need for a compiler or a native toolchain.
ld/
* testsuite/ld-unique/unique.d: New test.
* testsuite/ld-unique/unique.exp: Run the new test. Adjust
messages for compiled tests.
Nowadays, read_memory may throw NOT_AVAILABLE_ERROR (it is done by
patch http://sourceware.org/ml/gdb-patches/2013-08/msg00625.html)
however, read_stack and read_code still throws MEMORY_ERROR only. This
causes PR 19947, that is prologue unwinder is unable unwind because
code memory isn't available, but MEMORY_ERROR is thrown, while unwinder
catches NOT_AVAILABLE_ERROR.
#0 memory_error (err=err@entry=TARGET_XFER_E_IO, memaddr=memaddr@entry=140737349781158) at /home/yao/SourceCode/gnu/gdb/git/gdb/corefile.c:217
#1 0x000000000065f5ba in read_code (memaddr=memaddr@entry=140737349781158, myaddr=myaddr@entry=0x7fffffffd7b0 "\340\023<\001", len=len@entry=1)
at /home/yao/SourceCode/gnu/gdb/git/gdb/corefile.c:288
#2 0x000000000065f7b5 in read_code_unsigned_integer (memaddr=memaddr@entry=140737349781158, len=len@entry=1, byte_order=byte_order@entry=BFD_ENDIAN_LITTLE)
at /home/yao/SourceCode/gnu/gdb/git/gdb/corefile.c:363
#3 0x00000000004717e0 in amd64_analyze_prologue (gdbarch=gdbarch@entry=0x13c13e0, pc=140737349781158, current_pc=140737349781165, cache=cache@entry=0xda0cb0)
at /home/yao/SourceCode/gnu/gdb/git/gdb/amd64-tdep.c:2267
#4 0x0000000000471f6d in amd64_frame_cache_1 (cache=0xda0cb0, this_frame=0xda0bf0) at /home/yao/SourceCode/gnu/gdb/git/gdb/amd64-tdep.c:2437
#5 amd64_frame_cache (this_frame=0xda0bf0, this_cache=<optimised out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/amd64-tdep.c:2508
#6 0x000000000047214d in amd64_frame_this_id (this_frame=<optimised out>, this_cache=<optimised out>, this_id=0xda0c50)
at /home/yao/SourceCode/gnu/gdb/git/gdb/amd64-tdep.c:2541
#7 0x00000000006b94c4 in compute_frame_id (fi=0xda0bf0) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:481
#8 get_prev_frame_if_no_cycle (this_frame=this_frame@entry=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1809
#9 0x00000000006bb6c9 in get_prev_frame_always_1 (this_frame=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1983
#10 get_prev_frame_always (this_frame=this_frame@entry=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1999
#11 0x00000000006bbe11 in get_prev_frame (this_frame=this_frame@entry=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:2241
#12 0x00000000006bc13c in unwind_to_current_frame (ui_out=<optimised out>, args=args@entry=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1485
The fix is to let read_stack and read_code throw NOT_AVAILABLE_ERROR too,
in order to align with read_memory.
gdb:
2016-05-04 Yao Qi <yao.qi@linaro.org>
PR gdb/19947
* corefile.c (read_memory): Rename it to ...
(read_memory_object): ... it. Add parameter object.
(read_memory): Call read_memory_object.
(read_stack): Likewise.
(read_code): Likewise.
This test currently uses [is_remote target] to check if the test is
supported. This is not quite correct, as the limitation is actually
that it requires support for "running", ruling out stub-like targets.
Therefore, it should check for use_gdb_stub.
This has no visible effect right now, but it will once we make the
native-gdbserver board non-dejagnu-remote.
gdb/testsuite/ChangeLog:
* gdb.base/solib-display.exp: Check for [use_gdb_stub] instead
of [is_remote target],
This patch introduces the use_gdb_stub procedure, which allows getting
the right value of the use_gdb_stub variable/property in any all
situations.
When calling it before the $use_gdb_stub global variable has been set,
it will return the value of the use_gdb_stub property from the board
file. This happens when tests want to bail out early (even before gdb
has been started) when the current test setup is a stub.
Otherwise, it returns the value of the $use_gdb_stub global.
It's possible for these two to differ when a test file overrides the
value of the global.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (use_gdb_stub): New procedure.
binutils* testsuite/lib/binutils-common.exp (is_elf_format): Add avr-*-*.
ld * testsuite/ld-elf/pr18735.d: Allow other symbols.
* testsuite/ld-elf/sec64k.exp: Skip 64ksec for avr.
* testsuite/ld-gc/pr14265.d: Allow other symbols.
* testsuite/ld-plugin/plugin.exp: Add PR ld/17973 to
plugin_tests only if check_shared_lib_support is true.
* testsuite/ld-selective/selective.exp: Add --section-start
flag for avr.
PR symtab/19914
* dwarf2read.c (open_and_init_dwp_file): Look at backlink if objfile
is separate debug file.
testsuite/
* gdb.dwarf2/dwp-sepdebug.c: New file.
* gdb.dwarf2/dwp-sepdebug.exp: New file.
Valgrind shows:
==26964== Invalid read of size 1
==26964== at 0x6E14100: __GI_strcmp (strcmp.S:180)
==26964== by 0x6DB55AA: setlocale (setlocale.c:238)
==26964== by 0x4E0455: _initialize_python() (python.c:1731)
==26964== by 0x786731: initialize_all_files() (init.c:319)
==26964== by 0x72EF0A: gdb_init(char*) (top.c:1929)
==26964== by 0x60BCAC: captured_main(void*) (main.c:863)
==26964== by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234)
==26964== by 0x60C608: gdb_main(captured_main_args*) (main.c:1165)
==26964== by 0x40CAEC: main (gdb.c:32)
==26964== Address 0x81d30a0 is 0 bytes inside a block of size 181 free'd
==26964== at 0x4C29CF0: free (vg_replace_malloc.c:530)
==26964== by 0x6DB5B65: setname (setlocale.c:201)
==26964== by 0x6DB5B65: setlocale (setlocale.c:388)
==26964== by 0x4E037F: _initialize_python() (python.c:1712)
==26964== by 0x786731: initialize_all_files() (init.c:319)
==26964== by 0x72EF0A: gdb_init(char*) (top.c:1929)
==26964== by 0x60BCAC: captured_main(void*) (main.c:863)
==26964== by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234)
==26964== by 0x60C608: gdb_main(captured_main_args*) (main.c:1165)
==26964== by 0x40CAEC: main (gdb.c:32)
The problem is doing this:
oldloc = setlocale (LC_ALL, NULL);
setlocale (LC_ALL, "");
...
setlocale (LC_ALL, oldloc);
I.e., the second setlocale call frees 'oldloc'.
From http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html :
"The returned string pointer might be invalidated or the string
content might be overwritten by a subsequent call to setlocale()."
gdb/ChangeLog:
2016-05-03 Pedro Alves <palves@redhat.com>
PR python/20037
* python/python.c (_initialize_python) [IS_PY3K]: xstrdup/xfree
oldloc.
This makes no sense -- strlen doesn't really ever fail with -1.
gdb/ChangeLog:
2016-05-03 Pedro Alves <palves@redhat.com>
* python/python.c (_initialize_python) [IS_PY3K]: Remove dead
code.
When handling absolute relocations for global symbols bind within the
shared object, AArch64 will generate one dynamic RELATIVE relocation,
but won't apply the value for this absolution relocations at static
linking stage. This is different from AArch64 gold linker and x86-64.
This is not a bug as AArch64 is RELA, there is only guarantee that
relocation addend is placed in the relocation entry. But some
system softwares originally writen for x86-64 might assume AArch64
bfd linker gets the same behavior as x86-64, then they could take
advantage of this buy skipping those RELATIVE dynamic relocations
if the load address is the same as the static linking address.
This patch makes AArch64 BFD linker applies absolution relocations at
static linking stage for scenario described above. Meanwhile old AArch64
android loader has a bug (PR19163) which relies on current linker behavior
as a workaround, so the same option --no-apply-dynamic-relocs added.
GDB's use of --dynamic-list to only export the proc-service symbols is
broken due to Python's "python-config --ldflags" saying we should link
with -export-dynamic, causing us to export _all_ extern symbols
anyway. On Fedora 23:
$ python-config --ldflags
-lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic
$ python3.4-config --ldflags
-L/usr/lib64 -lpython3.4m -lpthread -ldl -lutil -lm -Xlinker -export-dynamic
Having GDB export all its symbols leads to issues such as PR gdb/16818
(GDB crashes when using name for target remote hostname:port), where a
GDB symbol unintentionally preempts a symbol in one of the NSS modules
glibc loads into the process. NSS modules should not define symbols
outside the implementation namespace or the relevant standards, but,
alas, that's a longstanding and hard to fix issue. See libc-alpha
discussion at:
[symbol name space issues with NSS modules]
https://sourceware.org/ml/libc-alpha/2016-04/msg00130.html
Python should instead be either using GCC's symbol visibility feature
or -Wl,--dynamic-list as well, to only export Python API symbols, but,
it doesn't. There are bugs open upstream for that:
[Use -Wl,--dynamic-list=x.list, not -Xlinker -export-dynamic]
http://bugs.python.org/issue10112
[Use GCC visibility attrs in PyAPI_*]
http://bugs.python.org/issue11410
But that's taking a long while to resolve.
I thought of working around this Python issue by making GDB build with
-fvisibility=hidden, as Jan suggests in Python issue 10112, as then
Python's "-Xlinker -export-dynamic" has no effect. However, that
would need to be done in the whole source tree (bfd, libiberty, etc.),
and I think that would break GCC plugins, as I believe those have
access to all of GCCs symbols, by "design". So we'd need a new
configure switch, or have the libraries in the tree detect which of
GCC or GDB is being built, but that doesn't work, because the answer
can be "both" with combined builds...
So this patch instead works around Python's bug, by simply sed'ing
away "-Xlinker -export-dynamic" from the result of python-config.py
--ldflags, making -Wl,--dynamic-list work again as it used to. It's
ugly, but so is the bug...
Note that if -Wl,--dynamic-list doesn't work, we always link with
-rdynamic, so static Python should still work.
Tested on F23 with --python=python (Python 2.7) and
--python=python3.4.
gdb/ChangeLog:y
2016-05-03 Pedro Alves <palves@redhat.com>
* configure.ac (PYTHON_LIBS): Sed away "-Xlinker -export-dynamic".
* configure: Regenerate.
The -Wl,--dynamic-list test is currently broken on Fedora 23, when you
configure with --with-python=python3.4. We see:
configure:13741: checking for the dynamic export flag
configure:13796: gcc -o conftest -g3 -O0 -fno-strict-aliasing -DNDEBUG -fwrapv -Wl,--dynamic-list=/home/pedro/gdb/mygit/src/gdb/proc-service.list conftest.c -ldl -lncurses -lm -ldl -lpthread -ldl -lutil -lm -lpython3.4m -Xlinker -export-dynamic >&5
conftest.c:182:30: fatal error: python3.4/Python.h: No such file or directory
compilation terminated.
configure:13796: $? = 1
The correct -I path is in PYTHON_CPPFLAGS:
PYTHON_CPPFLAGS='-I/usr/include/python3.4m -I/usr/include/python3.4m'
(Other Python-related tests in the file are already doing this.)
gdb/ChangeLog:
2016-05-03 Pedro Alves <palves@redhat.com>
* configure.ac (checking for the dynamic export flag): Add
$PYTHON_CPPFLAGS to CPPFLAGS.
* configure: Regenerate.
This test seems to work with both native-gdbserver and
native-extended-gdbserver, so I removed the remote check.
When running with native-gdbserver (a stub-like target), detach makes
gdbserver stop and gdb disconnect. runto_main just spawns a brand new
gdbserver. So it tests the exact same thing twice. It doesn't hurt
though.
With native-extended-gdbserver, the test is probably a bit more useful
(and similar to native). It tests running/detaching twice using the
same gdb/gdbserver instances, since with extended-remote, you can
detach/attach/run all you want, unlike with remote.
gdb/testsuite/ChangeLog:
* gdb.base/detach.exp: Remove is_remote check.
The comment says that we can't use runto_main here becore it doesn't
know how to handle annotation. Instead, the test puts a breakpoint at
main and calls run by hand. Therefore, it can't work with stub targets,
since they can't "run". The check should be then changed to check the
use_gdb_stub variable instead of [is_remote target].
But as an alternative, we can just use runto_main and enable annotations
after, since the "run to main" part is not really part of what we want
to test.
I also removed the "set test..." line that is unused.
gdb/testsuite/ChangeLog:
* gdb.base/annota-input-while-running.exp: Don't check for
[is_remote target]. Enable annotations after running to main.
Remove unused "set test..." line.
* windows-nat.c (_initialize_check_for_gdb_ini): Fix off-by-one
error in allocation of space for "$HOME/.gdbinit" string. This
caused GDB to abort on startup whenever a '~/gdb.ini' file was
actually found, because xsnprintf would hit an assertion
violation.
Set interpreter in x86 create_dynamic_sections to make this information
available to x86 check_relocs.
* elf32-i386.c (elf_i386_size_dynamic_sections): Move interp
setting to ...
(elf_i386_create_dynamic_sections): Here.
* elf64-x86-64.c (elf_x86_64_size_dynamic_sections): Move
interp setting to ...
(elf_x86_64_create_dynamic_sections): Here.
When UNDEFINED_WEAK_RESOLVED_TO_ZERO is checked to convert load via
GOT, has_got_reloc is always TRUE. This patch adds GOT_RELOC, which
is TRUE in x86 convert_load, to UNDEFINED_WEAK_RESOLVED_TO_ZERO.
* elf32-i386.c (UNDEFINED_WEAK_RESOLVED_TO_ZERO): Take GOT_RELOC
and replace (EH)->has_got_reloc with GOT_RELOC.
(elf_i386_fixup_symbol): Pass has_got_reloc to
UNDEFINED_WEAK_RESOLVED_TO_ZERO.
(elf_i386_allocate_dynrelocs): Likewise.
(elf_i386_relocate_section): Likewise.
(elf_i386_finish_dynamic_symbol): Likewise.
(elf_i386_convert_load): Pass TRUE to
UNDEFINED_WEAK_RESOLVED_TO_ZERO.
* elf64-x86-64.c (UNDEFINED_WEAK_RESOLVED_TO_ZERO): Take
GOT_RELOC and replace (EH)->has_got_reloc with GOT_RELOC.
(elf_x86_64_fixup_symbol): Pass has_got_reloc to
UNDEFINED_WEAK_RESOLVED_TO_ZERO.
(elf_x86_64_allocate_dynrelocs): Likewise.
(elf_x86_64_relocate_section): Likewise.
(elf_x86_64_finish_dynamic_symbol): Likewise.
(elf_x86_64_convert_load): Pass TRUE to
UNDEFINED_WEAK_RESOLVED_TO_ZERO.
There is no need to download source if we aren't on remote host.
Otherwise, each ld test run on local host leaves behind a couple
test files.
* config/default.exp (NOPIE_CFLAGS): Download source only on
remote host.
(NOPIE_LDFLAGS): Likewise.
* testsuite/lib/ld-lib.exp (check_lto_available): Likewise.
(check_lto_fat_available): Likewise.
(check_lto_shared_available): Likewise.
(check_ifunc_available): Likewise.
(check_ifunc_attribute_available): Likewise.
* readelf.c (is_32bit_pcrel_reloc): Return true if reloc is 32-bit
PC relocation for AVR target.
(is_none_reloc): Return true if reloc is any of AVR diff
relocations.
No need to relocate section when check_relocs failed.
* elf32-i386.c (check_relocs_failed): New.
(elf_i386_check_relocs): Set check_relocs_failed on error.
(elf_i386_relocate_section): Skip if check_relocs failed.
PR 19938
bfd * elf-bfd.h (struct elf_backend_data): Rename
elf_backend_set_special_section_info_and_link to
elf_backend_copy_special_section_fields.
* elfxx-target.h: Likewise.
* elf.c (section_match): Ignore the SHF_INFO_LINK flag when
comparing section flags.
(copy_special_section_fields): New function.
(_bfd_elf_copy_private_bfd_data): Copy the EI_ABIVERSION field.
Perform two scans over special sections. The first one looks for
a direct mapping between the output section and an input section.
The second scan looks for a possible match based upon section
characteristics.
* elf32-arm.c (elf32_arm_copy_special_section_fields): New
function. Handle setting the sh_link field of SHT_ARM_EXIDX
sections.
* elf32-i386.c (elf32_i386_set_special_info_link): Rename to
elf32_i386_copy_solaris_special_section_fields.
* elf32-sparc.c (elf32_sparc_set_special_section_info_link):
Rename to elf32_sparc_copy_solaris_special_section_fields.
* elf64-x86-64.c (elf64_x86_64_set_special_info_link): Rename to
elf64_x86_64_copy_solaris_special_section_fields.
binutils* readelf.c (get_solaris_segment_type): New function.
(get_segment_type): Call it.
Just like completion doesn't show deprecated commands, I think that help
should not list them, so that we don't incite users to use them.
gdb/ChangeLog:
* cli/cli-decode.c (help_cmd_list): Do not list commands that
are deprecated.
This patch adds a test for tracepoints enabling/disabling, which
didn't work properly for fast tracepoints on big endian systems.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-enable-disable.exp: New file.
* gdb.trace/trace-enable-disable.c: New file.
I am sending this fix on behalf of Par Olsson, as a follow-up of this
one:
https://www.sourceware.org/ml/gdb-patches/2015-10/msg00196.html
This problem is exposed when enabling/disabling fast tracepoints on big
endian machines. The flag is defined as an int8_t, but is written from
gdbserver as an integer (usually 32 bits). When the agent code reads it
as an int8_t, it only considers the most significant byte, which is
always 0.
Also, we were writing 32 bits in an 8 bits field, so the write would
overflow, but since the following bytes are padding (the next field is
an uint64_t), it luckily didn't cause any issue on little endian
systems.
The fix was originally tested on ARM big endian systems, but I don't
have access to such a system. However, thanks to Marcin's PowerPC fast
tracepoint patches and gcc110 (big endian Power7) on the gcc compile
farm, I was able to reproduce the problem, test the fix and write a
test (the following patch).
gdb/gdbserver/ChangeLog:
YYYY-MM-DD Par Olsson <par.olsson@windriver.com>
* tracepoint.c (write_inferior_int8): New function.
(cmd_qtenable_disable): Write enable flag using
write_inferior_int8.
Some fast tracepoints tests make sure that the in-process agent library
is properly loaded, by searching for the library name in "info
sharedlibrary".
Originally, it would search for the full path. Since patch "Make ftrace
tests work with remote targets" [1], the "runtime" location of the IPA,
in the standard output directory, is not the same as the original
location, in the gdbserver build directory. Therefore, the patch
changed the checks:
gdb_test "info sharedlibrary" ".*${libipa}.*" "IPA loaded"
to
gdb_test "info sharedlibrary" ".*[file tail ${libipa}].*" "IPA loaded"
so that only the "libinproctrace.so" part would be searched for.
Antoine (in CC) pointed out that I missed some, so I have to update
them. In the mean time, I noticed that I missed a few test failures:
adding the SONAME to the IPA makes it possible for the test executable
to erroneously pick up libinproctrace.so from /usr/lib if the test
harness failed to put the libinproctrace.so we want to test in the right
place. To mitigate that kind of error in the future, we can use the
return value of gdb_load_shlib (the path of the "runtime" version of the
library) and use that to search in the output of info sharedlibrary.
When testing locally, gdb_load_shlib returns the full normalized path of
the destination library, which the test executable should use e.g.:
/path/to/gdb/testsuite/outputs/gdb.trace/thetest/libinproctrace.so
My testing showed that it was the same path that gdb displayed in info
sharedlibrary. If the test executable picks up another
libinproctrace.so, the test will fail.
When testing remotely, gdb_load_shlib/gdb_remote_download only returns
us "libinproctrace.so", so the situation doesn't really change. If
there is a rogue libinproctrace.so in /usr/lib on the target and we fail
to download ours, it might cover up a test failure. But that situation
is probably still better than the original one, where it wasn't possible
to test remotely using the IPA at all.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e774b13c3b81ac2599812adf058796948ce7e95
gdb/testsuite/ChangeLog:
* gdb.arch/ftrace-insn-reloc.exp: Save gdb_load_shlib result,
use it in info sharedlibrary test.
* gdb.trace/ftrace-lock.exp: Likewise.
* gdb.trace/ftrace.exp: Likewise.
* gdb.trace/range-stepping.exp: Likewise.
* gdb.trace/trace-break.exp: Likewise.
* gdb.trace/trace-condition.exp: Likewise.
* gdb.trace/trace-mt.exp: Likewise.
Hi,
I happen to see that field need_step_over in struct lwp_info is only
used to print a debug info. need_step_over is set in linux_wait_1
when breakpoint_here is true, however, we check breakpoint_here too in
need_step_over_p and do the step over. I think we don't need field
need_step_over, and check breakpoint_here directly in need_step_over_p.
This field was added in this patch
https://sourceware.org/ml/gdb-patches/2010-03/msg00605.html and the code
wasn't changed much since then.
This patch is to remove it.
gdb/gdbserver:
2016-04-28 Yao Qi <yao.qi@linaro.org>
* linux-low.h (struct lwp_info) <need_step_over>: Remove.
* linux-low.c (linux_wait_1): Update.
(need_step_over_p): Likewise.
H.J. Lu
Simon Marchi
Yao Qi
GDB Administrator
Ulrich Weigand
Maciej W. Rozycki
Claudiu Zissulescu
Senthil Kumar Selvaraj
Doug Evans
Don Breazeal
Nick Clifton
Pedro Alves
Jiong Wang
Szabolcs Nagy
Pitchumani Sivanupandi
Kyrylo Tkachov
Eli Zaretskii
Par Olsson