Before this change, trying to call an overloaded function with at least
one character literal in argument would fail. For instance, given these
two functions:
function F (C : Character) return Integer is
begin
return Character'Pos (C);
end F;
function F (I : Integer) return Integer is
begin
return -I;
end F;
We would get the following GDB session:
(gdb) p f('A')
$1 = -65
(gdb) p f(1)
$1 = -1
This is wrong because the first call should select the first F function
and thus return 65.
The root problem is that ada-lang.c:ada_language_arch_info stores in
string_char_type a type whose code is TYPE_CODE_INT instead of
TYPE_CODE_CHAR. As a result, all parsed character literals are turned
into integer values and during overload matching, the TYPE_CODE_CHAR
formal rejects the TYPE_CODE_INT actual.
This change turns string_char_type into a true TYPE_CODE_CHAR type in
ada-lang.c so that we have instead the expected:
(gdb) p f('A')
$1 = 65
gdb/ChangeLog:
* ada-lang.c (ada_language_arch_info): Create a TYPE_CODE_CHAR
type instead of a TYPE_CODE_INT one for the string_char_type
and the ada_primitive_type_char types.
gdb/testsuite/ChangeLog:
* gdb.ada/funcall_char.exp: New testcase.
* gdb.ada/funcall_char/foo.adb: New file.
Tested on x86_64-linux, no regression.
PR binutils/18879
* readelf.c (get_unwind_section_word): Check for negative offsets
and very small sections.
(dump_arm_unwind): Warn if the table offset is too large.
Nowadays, if user requests HW watchpoint to monitor a large memory area
or unaligned area, aarch64 GDB will split into multiple aligned areas,
and use multiple debugging registers to watch them. However, the
registers are not updated in a transaction way. GDBserver doesn't revert
updates in previous iterations if some debugging registers fail to update
due to some reason, like no free debugging registers available, in the
latter iteration. For example, if we have a char buf[34], and watch buf
in gdb,
(gdb) watch buf
Hardware watchpoint 2: buf
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (Thread 13466)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: step-over queue now empty
infrun: resuming [Thread 13466] for step-over
Sending packet: $m410838,22#35...Packet received: 00000000000000000000000000000000000000000000000000000000000000000000
infrun: skipping breakpoint: stepping past insn at: 0x400524
infrun: skipping breakpoint: stepping past insn at: 0x400524
Sending packet: $Z2,410838,22#80...Packet received: E01 <----- [1]
Packet Z2 (write-watchpoint) is supported
Sending packet: $Z0,7fb7fe0a8c,4#43...Packet received: OK
Warning:
Could not insert hardware watchpoint 2.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
GDB receives E01 for Z2 packet [1] but GDBserver updates the debugging
register status,
insert_point (addr=0x00410838, len=34, type=hw-write-watchpoint):
BREAKPOINTs:
BP0: addr=0x0, ctrl=0x00000000, ref.count=0
BP1: addr=0x0, ctrl=0x00000000, ref.count=0
BP2: addr=0x0, ctrl=0x00000000, ref.count=0
BP3: addr=0x0, ctrl=0x00000000, ref.count=0
BP4: addr=0x0, ctrl=0x00000000, ref.count=0
BP5: addr=0x0, ctrl=0x00000000, ref.count=0
WATCHPOINTs:
WP0: addr=0x410850, ctrl=0x00001ff5, ref.count=1
WP1: addr=0x410848, ctrl=0x00001ff5, ref.count=1
WP2: addr=0x410840, ctrl=0x00001ff5, ref.count=1
WP3: addr=0x410838, ctrl=0x00001ff5, ref.count=1
four debugging registers can not monitor 34-byte long area, so the last
iteration of updating debugging register state fails but previous
iterations succeed. This makes GDB think no HW watchpoint is inserted
but some debugging registers are used.
This problem was exposed by "watch buf" gdb.base/watchpoint.exp with
aarch64 GDBserver debugging arm 32-bit program. The buf is 30-byte long
but 4-byte aligned, and four debugging registers can't cover 34-byte
(extend 4 bytes to be 8-byte aligned) area. However, this problem
does exist on non-multi-arch debugging scenario as well.
This patch moves code in aarch64_linux_region_ok_for_hw_watchpoint to
aarch64_linux_region_ok_for_watchpoint in nat/aarch64-linux-hw-point.c.
Then, checks with aarch64_linux_region_ok_for_watchpoint, like what we
are doing in GDB. If the region is OK, call aarch64_handle_watchpoint.
Regression tested on aarch64 with both 64-bit program and 32-bit
program. Some fails in gdb.base/watchpoint.exp are fixed.
gdb:
2015-09-03 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_linux_region_ok_for_hw_watchpoint):
Move code to aarch64_linux_region_ok_for_watchpoint. Call
aarch64_linux_region_ok_for_watchpoint.
* nat/aarch64-linux-hw-point.c (aarch64_linux_region_ok_for_watchpoint):
New function.
* nat/aarch64-linux-hw-point.h (aarch64_linux_region_ok_for_watchpoint):
Declare it.
gdb/gdbserver:
2015-09-03 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_insert_point): Call
aarch64_handle_watchpoint if aarch64_linux_region_ok_for_watchpoint
returns true.
Since the type whose name is being set is now being allocated on the
gdbarch obstack, we should allocate its TYPE_NAME on the obstack too.
This reduces the number of individual valgrind warnings for the command
"gdb gdb" from ~300 to ~150.
Tested on x86_64-unknown-linux-gnu.
gdb/ChangeLog:
* gdb_obstack.h (obstack_strdup): Declare.
* gdb_obstack.c (obstack_strdup): Define.
* gdbarch.sh (gdbarch_obstack_strdup): Declare and define.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbtypes.c (arch_type): Use gdbarch_obstack_strdup.
Following commit 8f57eec2fb ("Use gdbarch obstack to allocate types in
alloc_type_arch") it is no longer the case that the type returned by
copy_type_recursive is allocated using malloc. Because the function
uses alloc_type_arch internally, the new type is now allocated on the
gdbarch associated with the type, and is thus owned by that gdbarch.
gdb/ChangeLog:
* gdbtypes.c (copy_type_recursive): Update documentation.
Turn IFUNC symbols from shared libraries into normal FUNC symbols when
we are resolving symbol references, instead of when we are writing out
the symbol table.
PR gold/18886
* resolve.cc (Symbol::override_base): Turn IFUNC symbols from
shared libraries into normal FUNC symbols.
* symtab.cc (Symbol_table::sized_write_symbol): Assert IFUNC
symbols aren't from shared libraries.
Gold version of a4b6fadd. Don't emit long branch or plt branch stubs
to save/restore functions. Copy them instead.
PR 18878
* powerpc.cc (Target_powerpc): Add savres_section_ and accessor.
(Target_powerpc::Branch_info::make_stub): Determine whether long
branch stub is for save/restore function.
(Branch_stub_ent): Add save_res_, and extra parm to constructor.
(Stub_table): Add need_save_res_.
(Stub_table:clear_stubs): Clear need_save_res_.
(Stub_table:set_address_and_size): Add save/restore section size.
(Stub_table::add_long_branch_entry): Add save_res param. Set
need_save_res_, but don't add space for save/restore stubs.
(Stub_table::find_long_branch_entry): Return offset to local copy
of save/restore func.
(Stub_table::do_write): Don't output save/restore stubs. Instead
copy the save/restore functions.
(Output_data_save_res:contents): New accessor.
(Target_powerpc::define_save_restore_funcs): Set savres_section_.
Yet another BuildBot e-mail, yet another breakage on RHEL-7.1 s390x
(which uses an older GCC). This time,
solib-svr4.c:solib_event_probe_action has the probe_argc variable,
which is now inside a TRY..CATCH and therefore needs to be
initialized. Pushed as obvious.
gdb/ChangeLog:
2015-09-01 Sergio Durigan Junior <sergiodj@redhat.com>
* solib-svr4.c (solib_event_probe_action): Initialize 'probe_argc'
as zero.
BuildBot e-mailed me to let me know that my last commit broke GDB on
RHEL-7.1 s390x. On solib-svr4.c:svr4_handle_solib_event, 'val' now
needs to be initialized as NULL because it is inside a TRY..CATCH
block. This patch does that. Pushed as obvious.
gdb/ChangeLog:
2015-09-01 Sergio Durigan Junior <sergiodj@redhat.com>
* solib-svr4.c (svr4_handle_solib_event): Initialize 'val' as NULL
This patch is intended to make the interaction between the
probes-based dynamic linker interface and the SystemTap SDT probe code
on GDB more robust. It does that by wrapping the calls to the probe
API with TRY...CATCH'es, so that any exception thrown will be caught
and handled properly.
The idea for this patch came from
<https://bugzilla.redhat.com/show_bug.cgi?id=1196181>, which is a bug
initially filed against Fedora GDB (but now under Fedora GLIBC). This
bug happens on armhfp (although it could happen on other targets as
well), and is triggered because GCC generates a strange argument for
one of the probes used by GDB in the dynamic linker interface. As can
be seen in the bug, this argument is "-4@.L1052".
I don't want to discuss the reasons for this argument to be there
(this discussion belongs to the bug, or to another thread), but GDB
could definitely do a better error handling here. Currently, one sees
the following message when there is an error in the probes-based
dynamic linker interface:
(gdb) run
Starting program: /bin/inferior
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
Cannot parse expression `.L976 4@r4'.
(gdb)
Which means that one needs to explicitly issue a "continue" command to
make GDB continue running the inferior, even though this error is not
fatal and GDB will fallback to the old interface automatically.
This is where this patch helps: it makes GDB still print the necessary
warnings or error messages, but it *also* does not stop the inferior
unnecessarily.
I have tested this patch on the systems where this error happens, but
I could not come up with a way to create a testcase for it.
Nevertheless, it should be straightforward to see that this patch does
improve the current situation.
gdb/ChangeLog:
2015-09-01 Sergio Durigan Junior <sergiodj@redhat.com>
* solib-svr4.c (solib_event_probe_action): Call
get_probe_argument_count using TRY...CATCH.
(svr4_handle_solib_event): Likewise, for evaluate_probe_argument.
This patch improves the error reporting when handling SystemTap SDT
probes. "Handling", in this case, mostly means "parsing".
On gdb/probe.h, only trivial changes on functions' comments in order
to explicitly mention that some of them can throw exceptions. This is
just to make the API a bit more clear.
On gdb/stap-probe.c, I have s/internal_error/error/ on two functions
that are responsible for parsing specific bits of the probes'
arguments: stap_get_opcode and stap_get_expected_argument_type. It is
not correct to call internal_error on such situations because it is
not really GDB's fault if the probes have malformed arguments. I also
improved the error reported on stap_get_expected_argument_type by also
including the probe name on it.
Aside from that, and perhaps most importantly, I added a check on
stap_get_arg to make sure that we don't try to extract an argument
from a probe that has no arguments. This check issues an
internal_error, because it really means that GDB is doing something it
shouldn't.
Although it can be considered almost trivial, and despite the fact
that I am the maintainer for this part of the code, I am posting this
patch for review. I will wait a few days, and if nobody has anything
to say, I will go ahead and push it.
gdb/ChangeLog:
2015-09-01 Sergio Durigan Junior <sergiodj@redhat.com>
* probe.h (struct probe_ops) <get_probe_argument_count,
evaluate_probe_argument, enable_probe, disable_probe>: Mention in
the comment that the function can throw an exception.
(get_probe_argument_count): Likewise.
(evaluate_probe_argument): Likewise.
* stap-probe.c (stap_get_opcode): Call error instead of
internal_error.
(stap_get_expected_argument_type): Likewise. Add argument
'probe'. Improve error message by mentioning the probe's name.
(stap_parse_probe_arguments): Adjust call to
stap_get_expected_argument_type.
(stap_get_arg): Add comment. Assert that 'probe->args_parsed' is
not zero. Call internal_error if GDB requests an argument but the
probe has no arguments.
Before this change, trying to complete an expression ending with an
ambiguous function name (i.e. for which there are multiple matches)
would display a menu with a prompt for the user to pick one. For
instance:
(gdb) p func<tab>Multiple matches for func
[0] cancel
[1] pack2.func at pack2.adb:5
[2] pack.func at pack.adb:5
>
This is not user friendly and actually triggered a segmentation fault
after the user did pick one. It is not clear whether the segmentation
fault needs a separate fix, but this is the only known case which
exhibits it at the moment, and this case must be fixed itself.
The problem lies in ada-lang.c (ada_resolve_function): when we got
multiple matches, we should not display the menu if we are in completion
mode. This patch adjusts the corresponding condition accordingly.
gdb/ChangeLog:
* ada-lang.c (ada_resolve_function): Do not ask the user what
match to use when in completion mode.
gdb/testsuite/ChangeLog:
* gdb.ada/complete.exp: Add "pck.ambiguous_func" to the relevant
expected outputs. Add two testcases for completing ambiguous
functions.
* gdb.ada/complete/aux_pck.adb: New file.
* gdb.ada/complete/aux_pck.ads: New file.
* gdb.ada/complete/foo.adb: Pull Aux_Pck and call the two
Ambiguous_Func functions.
* gdb.ada/complete/pck.ads: Add an Ambiguous_Func function.
* gdb.ada/complete/pck.adb: Likewise.
Tested on x86_64-linux, no regression.
We use its PLT entry to initialize function pointer at run-time. If
there is no other usage for the PLT entry, we can generate run-time
function pointer relocations in read-write section, which can be
resolved by dynamic linker, to initialize function pointers. It avoids
the extra indirect branch overhead in PLT.
bfd/
PR ld/18900
* elf32-i386.c (elf_i386_link_hash_entry): Add
func_pointer_refcount.
(elf_i386_link_hash_newfunc): Clear func_pointer_refcount.
(elf_i386_get_local_sym_hash): Likewise.
(elf_i386_copy_indirect_symbol): Also copy
func_pointer_refcount.
(elf_i386_check_relocs): Increment func_pointer_refcount.
(elf_i386_gc_sweep_hook): Decrement func_pointer_refcount.
(elf_i386_allocate_dynrelocs): Don't create the PLT entry if
there are only function pointer relocations which can be
resolved at run-time. Keep dynanamic relocations for run-time
function pointer initialization.
(elf_i386_relocate_section): Copy dynamic function pointer
relocations.
* elf64-x86-64.c (elf_x86_64_link_hash_entry): Add
func_pointer_refcount.
(elf_x86_64_link_hash_newfunc): Clear func_pointer_refcount.
(elf_x86_64_get_local_sym_hash): Likewise.
(elf_x86_64_copy_indirect_symbol): Also copy
func_pointer_refcount.
(elf_x86_64_check_relocs): Increment func_pointer_refcount.
(elf_x86_64_gc_sweep_hook): Decrement func_pointer_refcount.
(elf_x86_64_allocate_dynrelocs): Don't create the PLT entry if
there are only function pointer relocations which can be
resolved at run-time. Keep dynanamic relocations for run-time
function pointer initialization.
(elf_x86_64_relocate_section): Copy dynamic function pointer
relocations.
ld/testsuite/
PR ld/18900
* ld-i386/i386.exp: Run tests for PR ld/18900.
* ld-x86-64/x86-64.exp: Likewise.
* ld-i386/pr18900.out: New file.
* ld-i386/pr18900a.c: Likewise.
* ld-i386/pr18900a.c: Likewise.
* ld-i386/pr18900a.rd: Likewise.
* ld-i386/pr18900b.c: Likewise.
* ld-i386/pr18900b.rd: Likewise.
* ld-i386/pr18900c.c: Likewise.
* ld-x86-64/pr18900.out: Likewise.
* ld-x86-64/pr18900a.c: Likewise.
* ld-x86-64/pr18900a.rd: Likewise.
* ld-x86-64/pr18900b.c: Likewise.
* ld-x86-64/pr18900b.rd: Likewise.
* ld-x86-64/pr18900c.c: Likewise.
* ld-x86-64/mpx3.dd: Updated.
OPD lookup goes awry when .opd has been shuffled to remove unused
functions.
* elf64-ppc.c (ppc64_elf_maybe_function_sym): Adjust symbol value
if .opd section has been edited.
Don't emit long branch or plt branch stubs to save/restore functions.
Copy them instead. The problem is that plt branch stubs currently
trash r12, one of the parameters to some of the save/restore
functions, and there is no free register available to use instead of
r12.
6f20ed8a is prerequisite for this patch.
PR 18878
* elf64-ppc.c (ARRAY_SIZE): Define. Use throughout.
(enum ppc_stub_type): Add ppc_stub_save_res.
(struct map_stub): Add "next" and "needs_save_res".
(struct ppc_link_hash_entry): Add "save_res" flag.
(struct ppc_link_hash_table): Add "group".
(sfpr_define): Add stub_sec param. Define symbol in stub_sec if
stub_sec is non-null. Set "save_res".
(save_res_funcs): Make file scope, rename from funcs. Adjust uses.
(ppc64_elf_adjust_dynamic_symbol): Prohibit plt call to save_res syms.
(ppc_build_one_stub): Handle ppc_stub_save_res.
(ppc_size_one_stub): Set stub type to ppc_size_one_stub on finding
stub for linker defined save_res sym.
(group_sections): Init new fields of struct map_stub.
(ppc64_elf_size_stubs): Reserve space for save/restore func copy.
(ppc64_elf_build_stubs): Copy save/restore funcs to groups. Emit
alias syms too.
(ppc64_elf_relocate_section): Set destination for ppc_stub_save_res.
Sometimes these stubs don't need to change the low 16-bits of r2, so in
that case omit a useless addi r2,r2,0 insn. Also, change the get_r2off
error return from 0 to -1 since 0 is a valid return for ELFv2 -R objects.
* elf64-ppc.c (get_r2off): Return -1 on error.
(ppc_build_one_stub): Adjust for get_r2off change. Don't emit
addi r2,r2,0 on r2off stubs when the low 16-bit delta is zero.
(ppc_size_one_stub): Corresponding size changes for r2off stubs.
Add condition in test for -R objects.
Two organizational changes to the array of additional info kept for
sections.
1) Move group info into a per-group allocated struct, in preparation
for future changes that need per-group accounting.
2) Expand the array to include output sections, which simplifies
sizing and removes the need for a separate output section array.
* section.c (section_id): Make file scope.
(bfd_get_next_section_id): New function.
* elf64-ppc.c (struct map_stub): Remove toc_off field. Move decl.
(struct ppc_stub_hash_entry): Delete stub_sec and id_sec. Add
group. Update all uses.
(struct ppc_link_hash_table): Delete top_id, top_index, and
input_list. Add sec_info_arr_size. Rename stub_group to
sec_info, and make group info indirect. Update stub_group refs
throughout file.
(ppc_add_stub): Don't look for stub_sec on link_sec stub_group
entry.
(ppc_build_one_stub): Delete FIXME.
(ppc64_elf_setup_section_lists): Size htab->sec_info for all
sections, not just input sections. Don't create htab->input_list.
(ppc64_elf_next_input_section): Update to use sec_info union as
list pointer.
(PREV_SEC): Delete.
(group_sections): Pass "info" param rather than "htab". Iterate
over output sections rather than input_list. Use sec_info union
as list pointers. Alloc atruct map_stub, and return fail status.
* bfd-in2.h: Regenerate.
Small clean up to make a local variable const and remove a cast of NULL.
gdb/ChangeLog:
* tui/tui-data.c (tui_win_name): Make local variable const, remove
cast of NULL.
Use XSHAL_ABI value provided by xtensa-config.h to correctly initialize
xtensa_tdep.call_abi
This fixes calls to functions from GDB that otherwise fail with the
following assertion in call0 configuration:
gdb/regcache.c:602: internal-error: regcache_raw_read: Assertion
`regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.
2015-08-31 Max Filippov <jcmvbkbc@gmail.com>
gdb/
* xtensa-tdep.h (XTENSA_GDBARCH_TDEP_INSTANTIATE): Initialize
call_abi using XSHAL_ABI macro.
These int vars are really unsigned, so make them so.
* section.c (struct bfd_section): Make "id" and "index" unsigned.
* coff-rs6000.c (_bfd_xcoff_sizeof_headers): Adjust local var to suit.
* elf.c (elf_map_symbols): Likewise.
* elf64-ppc.c (sym_exists_at): Make "id" param unsigned.
(struct ppc_link_hash_table): Make "top_id" and "top_index" unsigned.
(ppc64_elf_setup_section_lists): Ditto for local vars.
* elf32-arm.c: Similarly to elf64-ppc.c.
* elf32-avr.c: Likewise.
* elf32-hppa.c: Likewise.
* elf32-m68hc1x.c: Likewise.
* elf32-metag.c: Likewise.
* elf32-nios2.c: Likewise.
* elfnn-aarch64.c: Likewise.
* simple.c (struct saved_offsets): Make "section_count" unsigned.
* bfd-in2.h: Regenerate.
Since the type whose name is being set is now being allocated on the
gdbarch obstack, we should allocate its TYPE_NAME on the obstack too.
This reduces the number of individual valgrind warnings for the command
"gdb gdb" from ~300 to ~150.
Tested on x86_64-unknown-linux-gnu.
gdb/ChangeLog:
* gdbarch.h (gdbarch_obstack_strdup): Declare.
* gdbarch.c (gdbarch_obstack_strdup): Define.
* gdbtypes.c (arch_type): Use it.
For the command "gdb gdb" valgrind currently reports 100s of individual
memory leaks, 500 of which originate solely out of the function
alloc_type_arch. This function allocates a "struct type" associated
with the given gdbarch using malloc but apparently the types allocated
by this function are never freed.
This patch fixes these leaks by making the function alloc_type_arch
allocate these gdbarch-associated types on the gdbarch obstack instead
of on the general heap. Since, from what I can tell, the types
allocated by this function are all fundamental "wired-in" types, such
types would not benefit from more granular memory management anyway.
They would likely live as long as the gdbarch is alive so allocating
them on the gdbarch obstack makes sense.
With this patch, the number of individual vargrind warnings emitted for
the command "gdb gdb" drops from ~800 to ~300.
Tested on x86_64-unknown-linux-gnu.
gdb/ChangeLog:
* gdbtypes.c (alloc_type_arch): Allocate the type on the given
gdbarch obstack instead of on the heap. Update commentary
accordingly.
solib_ops are installed as a property of the inferior gdbarch,
so they need to be systematically looked up via that architecture,
not some objfile architecture.
ChangeLog:
Revert:
2014-11-06 Doug Evans <xdje42@gmail.com>
* solib.c (solib_global_lookup): Fetch arch from objfile,
not target_gdbarch.
When debugging Cell/B.E. code, the cross-architecture frame unwinding
works by accessing data structures refered to by a thread-local variable
in the inferior. While accessing this variable via minimal symbol,
code would use BMSYMBOL_VALUE_ADDRESS to determine the offset of the
variable in the thread-local storage block.
This is incorrect, since it adds any relocation offset of the shared
library defining the TLS variable. That offset would be OK when
accessing the initial copy present in the .tbss section, but it must
not be applied to the offset of the variable in the TLS block at
runtime. Depending on whether or not the libspe2.so library was
prelinked, access to the variable would fail due to the incorrectly
relocated offset.
ChangeLog:
* ppc-linux-tdep.c (ppc_linux_spe_context_lookup): Do not
attempt to relocate a TLS variable offset.
With recent changes to inferior handling, parse_spufs_run needs to be
more careful in assumptions it makes. In particular, this patch:
- Bails out early if the current inferior has not yet been registered
(e.g. during fork procession) to avoid assertion failures in register
cache code.
- Sets inferior_ptid to the current ptid while calling target_read_memory
to make sure the correct process is accessed if parse_spufs_run is
called early when inferior_ptid has not yet been switched by the caller.
ChangeLog:
* spu-multiarch.c (parse_spufs_run): Bail out if inferior is not
registered yet. Set inferior_ptid while calling target_read_memory.
The Linux target and gdbserver now check the siginfo si_code
reported on a SIGTRAP to detect whether the trap indicates
a software breakpoint was hit.
Unfortunately, on Cell/B.E., the kernel uses an si_code value
of TRAP_BRKPT when a SW breakpoint was hit in PowerPC code,
but a si_code value of SI_KERNEL when a SW breakpoint was
hit in SPU code.
This patch updates Linux target and gdbserver to accept both
si_code values to indicate SW breakpoint on PowerPC.
ChangeLog:
* nat/linux-ptrace.h (GDB_ARCH_TRAP_BRKPT): Replace by ...
(GDB_ARCH_IS_TRAP_BRKPT): ... this. Add __powerpc__ case.
* linux-nat.c (check_stopped_by_breakpoint): Use
GDB_ARCH_IS_TRAP_BRKPT instead of GDB_ARCH_TRAP_BRKPT.
gdbserver/ChangeLog:
* linux-low.c (check_stopped_by_breakpoint): Use
GDB_ARCH_IS_TRAP_BRKPT instead of GDB_ARCH_TRAP_BRKPT.
Since we are no longer using thread events by default in linux-thread-db,
the find_new_threads_once routine contains an assertion that it should
never be called on a live inferior unless using thread events:
gdb_assert (!target_has_execution || thread_db_use_events ());
However, there is a code path from thread_db_get_thread_local_address
that will in fact call find_new_threads_once in some scenarios. In
particular, this is currently always triggered when starting up any
Cell/B.E. combined exeuctable.
To fix this, this patch removes the call to thread_db_find_new_threads_1
when the current thread was not yet detected. In its place, we now just
call thread_from_lwp to detect this one thread if necessary.
ChangeLog:
* linux-thread-db.c (thread_db_get_thread_local_address): If the
thread was not yet discovered, use thread_from_lwp instead of
calling thread_db_find_new_threads_1.
Pierre-Marie de Rodat
Nick Clifton
Yao Qi
H.J. Lu
Patrick Palka
GDB Administrator
Alan Modra
Sergio Durigan Junior
Andrew Burgess
Max Filippov
Doug Evans
Joel Brobecker
Simon Marchi
Ulrich Weigand