The g10 is an rl78 variant which has fewer registers. Aside from the
obvious addition of a new register_name() function which omits
registers which the g10 lacks, this change also updates the
return_value() function with the conventions specified by the ABI for
finding and setting return values.
* rl78-tdep.c (rl78_g10_register_name): New function.
(rl78_return_value): Add g10 support.
(rl78_gdbarch_init): Register rl78_g10_register_name for the
g10.
abfd->section_count unexpectedly changes between 218 and 248 in:
150 bfd_simple_get_relocated_section_contents (bfd *abfd,
[...]
218 saved_offsets = malloc (sizeof (struct saved_output_info)
219 * abfd->section_count);
[...]
230 _bfd_generic_link_add_symbols (abfd, &link_info);
[...]
248 bfd_map_over_sections (abfd, simple_restore_output_info, saved_offsets);
_bfd_generic_link_add_symbols increases section_count
and simple_restore_output_info later reads unallocated part of saved_offsets.
READ of size 8 at 0x601c0000c5c0 thread T0
#0 0x1124770 in simple_restore_output_info (.../gdb/gdb+0x1124770)
#1 0x10ecd51 in bfd_map_over_sections (.../gdb/gdb+0x10ecd51)
#2 0x1125150 in bfd_simple_get_relocated_section_contents (.../gdb/gdb+0x1125150)
bfd/
2014-02-17 Jan Kratochvil <jan.kratochvil@redhat.com>
PR binutils/16595
* simple.c (struct saved_offsets): New.
(simple_save_output_info): Use it for ptr.
(simple_restore_output_info): Use it for ptr. Check section_count.
(bfd_simple_get_relocated_section_contents): Use it for saved_offsets.
Moves assorted variables used to communicate between ld and bfd into
a struct, hooks it into the bfd link_hash_table early, and removes
all other places where such variables were passed piecemeal.
bfd/
* elf64-ppc.h (struct ppc64_elf_params): Define.
(ppc64_elf_init_stub_bfd, ppc64_elf_edit_opd, ppc64_elf_tls_setup,
ppc64_elf_setup_section_lists, ppc64_elf_size_stubs,
ppc64_elf_build_stubs): Update prototype.
* elf64-ppp.c (struct ppc_link_hash_table): Add params, delete other
fields now in params. Adjust code throughout file.
(ppc64_elf_init_stub_bfd): Delete "abfd" parameter, add "params".
Save params pointer in htab.
(ppc64_elf_edit_opd, ppc64_elf_tls_setup,
ppc64_elf_setup_section_lists, ppc64_elf_size_stubs,
ppc64_elf_build_stubs): Remove parameters now in "params".
ld/
* emultemps/ppc64elf.em (params): New static struct replacing
various other static vars. Adjust code throughout file.
This fixes the glaring error that the ppc476 workaround wasn't
actually enabled for ld -r, and adjusts relocations to match moved
code.
bfd/
* elf32-ppc.c (ppc_elf_relocate_section): Move relocs on insns
patched for ppc476 workaround. Reapply branch taken/not taken
relocs.
ld/
* emultempl/ppc32elf.em (ppc_after_open_output): Really enable
ppc476 workaround for ld -r.
A recent change (commit 3398af6aa3)
in gnu-nat.c causes the some missing-prototypes warnings,
../../../git/gdb/gnu-nat.c:1864:1: error: no previous prototype for 'S_proc_pid2task_reply' [-Werror=missing-prototypes]
../../../git/gdb/gnu-nat.c:1866:1: error: no previous prototype for 'S_proc_task2pid_reply' [-Werror=missing-prototypes]
../../../git/gdb/gnu-nat.c:1868:1: error: no previous prototype for 'S_proc_task2proc_reply' [-Werror=missing-prototypes]
A new macro ILL_RPC was added recently, which defines some external
functions. However, they are not declared and GCC complains about this.
This patch is to add the declarations of these external function in
macro ILL_RPC.
gdb:
2014-02-17 Yao Qi <yao@codesourcery.com>
* gnu-nat.c (ILL_RPC): Declare defined function.
../../../git/gdb/gnu-nat.c: In function 'gnu_read_inferior':
../../../git/gdb/gnu-nat.c:2282:3: error: pointer targets in passing argument 5 of 'vm_read' differ in signedness [-Werror=pointer-sign]
In file included from /home/yao/Software/hurd-toolchain/bin/../i686-pc-gnu/libc/usr/include/mach.h:38:0,
from ./nm.h:23,
from ../../../git/gdb/defs.h:500,
from ../../../git/gdb/gnu-nat.c:23:
/home/yao/Software/hurd-toolchain/bin/../i686-pc-gnu/libc/usr/include/mach/mach_interface.h:843:15: note: expected 'mach_msg_type_number_t *' but argument is of type 'int *'
../../../git/gdb/gnu-nat.c: In function 'gnu_write_inferior':
../../../git/gdb/gnu-nat.c:2339:4: error: pointer targets in passing argument 5 of 'vm_read' differ in signedness [-Werror=pointer-sign]
In file included from /home/yao/Software/hurd-toolchain/bin/../i686-pc-gnu/libc/usr/include/mach.h:38:0,
from ./nm.h:23,
from ../../../git/gdb/defs.h:500,
from ../../../git/gdb/gnu-nat.c:23:
/home/yao/Software/hurd-toolchain/bin/../i686-pc-gnu/libc/usr/include/mach/mach_interface.h:843:15: note: expected 'mach_msg_type_number_t *' but argument is of type 'int *'
This patch fixes these warnings.
gdb:
2014-02-17 Yao Qi <yao@codesourcery.com>
* gnu-nat.c (gnu_read_inferior): Change 'copy_count' type to
mach_msg_type_number_t.
(gnu_write_inferior): Likewise.
I've seen some -Wformat warnings when build native gdb for hurd.
../../../git/gdb/gnu-nat.c:2384:8: error: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'vm_address_t' [-Werror=format]
../../../git/gdb/gnu-nat.c:2394:8: error: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'vm_address_t' [-Werror=format]
../../../git/gdb/gnu-nat.c: In function 'steal_exc_port':
../../../git/gdb/gnu-nat.c:2898:5: error: format '%d' expects argument of type 'int', but argument 2 has type 'mach_port_t' [-Werror=format]
in usr/include/mach/port.h, we have:
typedef vm_offset_t mach_port_t;
and in usr/include/mach/machine/vm_types.h, we have:
typedef unsigned long vm_offset_t;
so this patch changes '%d' to '%lu' in format string for mach_port_t
variables.
Similarly, in usr/include/mach/std_types.h, we have,
typedef vm_offset_t vm_address_t;
this patch also changes '%x' to '%lx' in gnu_write_inferior.
gdb:
2014-02-17 Yao Qi <yao@codesourcery.com>
* gnu-nat.c (proc_get_exception_port): Use 'lu' insetad of 'd'
in format string.
(proc_steal_exc_port, make_proc, inf_set_pid): Likewise.
(inf_validate_procs, inf_signal): Likewise.
(S_exception_raise_request): Likewise.
(do_mach_notify_dead_name): Likewise.
(steal_exc_port): Likewise.
(gnu_read_inferior): Change 'copy_count''s type to
mach_msg_type_number_t.
(gnu_write_inferior): Likewise. Use 'lx' instead of 'x' in
format string.
If GDB has crashed then gdb_spawn_id still exists (although it does not work).
So my patch does not change anything. And also currently it will leave the
stale gdbserver running anyway.
In general if gdb_spawn_id does not exist then send_gdb + gdb_expect just do
not make sense anyway. So this patch just prevents the error in such case.
The killing of stale gdbserver could be improved multiple ways (also as
suggested by Pedro in the original thread) but that is IMO outside of the
scope of this patch. Apparently if there is no good response from GDB then
gdb_finish() should try to call gdb_start just to kill that gdbserver, IIUC.
gdb/testsuite/
2014-02-16 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix "ERROR: no fileid for" in the testsuite.
* lib/gdb.exp (gdb_finish): Check gdb_spawn_id.
Message-ID: <20140206205814.GA18495@host2.jankratochvil.net>
In commit 98882a2651, STARTUP_WITH_SHELL was made
a runtime toggle, startup-with-shell. The Hurd code was missed to be adjusted;
it had a value hard-coded instead of using START_INFERIOR_TRAPS_EXPECTED. Fix
that, and also simplify gnu-nat's pending_execs handling from counting to just
a flag.
gdb/
* gnu-nat.c (struct inf): Change pending_execs member to a 1-bit
flag. Adjust all users; in particular...
(gnu_wait): ..., don't decrement its value in here...
(gnu_create_inferior): ..., and instead set the flag in here,
around the startup_inferior call, and call that one with
START_INFERIOR_TRAPS_EXPECTED.
gdb/
* reply_mig_hack.awk: In phase 5, keep going if we have not yet
collected the type check structures.
Based on a patch by David Michael <fedora.dm0@gmail.com>.
The %fsr register is not being properly accessed from gdb in
sparc64. This is because sparc64_supply_fpregset and
sparc64_collect_fpregset are using the offsets from the
sparc32_bsd_fpregset constant instead of sparc64_bsd_fpregset.
This patch fixes this by registering the proper offsets for
sparc64-linux targets.
2014-02-14 Jose E. Marchesi <jose.marchesi@oracle.com>
* sparc64-linux-nat.c (_initialize_sparc64_linux_nat): Register
the proper offsets to access fpregset_t.
* gdb.dwarf2/Makefile.in (EXECUTABLES): Add dwp-symlink.
(MISCELLANEOUS): New variable.
(clean): rm -rf $(MISCELLANEOUS).
* gdb.dwarf2/dwp-symlink.exp: Test the case where the executable and
dwp live in the same directory as symlinks, with each symlink pointed
to a differently named file in a different directory.
This updates all the comments in rsp-low.[ch], now that the
unification has been completed.
2014-02-12 Tom Tromey <tromey@redhat.com>
* common/rsp-low.c: Update comments.
* common/rsp-low.h: Update comments.
unhexify and hex2bin are identical, so this removes unhexify. The
particular choice of which to keep was made on the basis of
parallelism with the earlier patch that removed hexify.
2014-02-12 Tom Tromey <tromey@redhat.com>
* common/rsp-low.h (unhexify): Don't declare.
* common/rsp-low.c (unhexify): Remove.
2014-02-12 Tom Tromey <tromey@redhat.com>
* server.c (handle_query, handle_v_run): Use hex2bin, not
unhexify.
* tracepoint.c (cmd_qtdpsrc, cmd_qtdv, cmd_qtnotes): Likewise.
convert_int_to_ascii is identical to bin2hex. This removes the
former. In this case I made the choice of which to keep on the basis
that I consider the name bin2hex to be superior to
convert_int_to_ascii.
2014-02-12 Tom Tromey <tromey@redhat.com>
* common/rsp-low.h (convert_int_to_ascii): Don't declare.
* common/rsp-low.c (convert_int_to_ascii): Remove.
2014-02-12 Tom Tromey <tromey@redhat.com>
* ax.c (gdb_unparse_agent_expr): Use bin2hex, not
convert_int_to_ascii.
* regcache.c (registers_to_string, collect_register_as_string):
Likewise.
* remote-utils.c (look_up_one_symbol, relocate_instruction):
Likewise.
* server.c (process_serial_event): Likewise.
* tracepoint.c (cmd_qtstatus, response_source, response_tsv)
(cmd_qtbuffer, cstr_to_hexstr): Likewise.
This removes hexify in favor of bin2hex.
The choice of which to keep was arbitrary.
2014-02-12 Tom Tromey <tromey@redhat.com>
* common/rsp-low.h (hexify): Don't declare.
* common/rsp-low.c (hexify): Remove.
2014-02-12 Tom Tromey <tromey@redhat.com>
* remote-utils.c (look_up_one_symbol, monitor_output): Use
bin2hex, not hexify.
* tracepoint.c (cmd_qtstatus): Likewise.
hexify had the same issue as bin2hex; and the fix is the same.
2014-02-12 Tom Tromey <tromey@redhat.com>
* common/rsp-low.c (hexify): Never take strlen of argument.
2014-02-12 Tom Tromey <tromey@redhat.com>
* remote-utils.c (monitor_output): Pass explicit length to
hexify.
Currently bin2hex may call strlen if the length argument is zero.
This prevents some function unification; and also it seems cleaner to
me not to have a special meaning for a zero length.
2014-02-12 Tom Tromey <tromey@redhat.com>
* common/rsp-low.c (bin2hex): Never take strlen of argument.
* remote.c (extended_remote_run, remote_rcmd)
(remote_download_trace_state_variable, remote_save_trace_data)
(remote_set_trace_notes): Update.
* tracepoint.c (encode_source_string, tfile_write_status)
(tfile_write_uploaded_tsv): Update.
This moves various low-level remote serial protocol bits into
common/rsp-low.[ch].
This is as close to a pure move as possible. There are some
redundancies remaining but those will be dealt with in a subsequent
patch.
Note that the two variants of remote_escape_output disagreed on the
treatment of "*". On the theory that quoting cannot hurt but the
absence possibly can, I chose the gdbserver variant to be the
canonical one.
2014-02-12 Tom Tromey <tromey@redhat.com>
* tracepoint.c: Include rsp-low.h.
* remote.h (hex2bin, bin2hex, unpack_varlen_hex): Don't declare.
* remote.c: Include rsp-low.h.
(hexchars, ishex, unpack_varlen_hex, pack_nibble, pack_hex_byte)
(fromhex, hex2bin, tohex, bin2hex, remote_escape_output)
(remote_unescape_input): Move to common/rsp-low.c.
* common/rsp-low.h: New file.
* common/rsp-low.c: New file.
* Makefile.in (SFILES): Add common/rsp-low.c.
(HFILES_NO_SRCDIR): Add common/rsp-low.h.
(COMMON_OBS): Add rsp-low.o.
(rsp-low.o): New target.
2014-02-12 Tom Tromey <tromey@redhat.com>
* tracepoint.c: Include rsp-low.h.
* server.c: Include rsp-low.h.
* remote-utils.h (convert_ascii_to_int, convert_int_to_ascii)
(unhexify, hexify, remote_escape_output, unpack_varlen_hex): Don't
declare.
* remote-utils.c: Include rsp-low.h.
(fromhex, hexchars, ishex, unhexify, tohex, hexify)
(remote_escape_output, remote_unescape_input, unpack_varlen_hex)
(convert_int_to_ascii, convert_ascii_to_int): Move to
common/rsp-low.c.
* regcache.c: Include rsp-low.h.
* ax.c: Include rsp-low.h.
* Makefile.in (SFILES): Add common/rsp-low.c.
(OBS): Add rsp-low.o.
(rsp-low.o): New target.
Since this change:
2014-02-12 Sanimir Agovic <sanimir.agovic@intel.com>
* nios2-tdep.c (nios2_stub_frame_base): Remove global.
nios2-tdep hasn't built:
../../binutils-gdb/gdb/nios2-tdep.c:1337:1: error: ‘nios2_stub_frame_base_address’ defined but not used [-Werror=unused-function]
This patch removes the offending function.
2014-02-12 Tom Tromey <tromey@redhat.com>
* nios2-tdep.c (nios2_stub_frame_base_address): Remove.
At least on OpenBSD PT_IO/PIOD_READ_AUXV can return sucessfully without
transferring any bytes. Arguably a kernel bug, but interpreting this as EOF
seems sensible.
gdb/ChangeLog:
* inf-ptrace.c (inf_ptrace_xfer_partial): Return TARGET_XFER_EOF
if a PT_IO ptrace request returns sucessfully but indicates that 0
bytes were transferred.
Ports for Hardvard architectures will typically have in their
pointer_to_address hook a check for TYPE_CODE_SPACE in their
"pointer_to_address" gdbarch method. E.g., rl78's:
/* Is it a code address? */
if (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_FUNC
|| TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_METHOD
|| TYPE_CODE_SPACE (TYPE_TARGET_TYPE (type))
|| TYPE_LENGTH (type) == 4)
return rl78_make_instruction_address (addr);
else
return rl78_make_data_address (addr);
The avr port is similar.
The vtable type is a struct type gdb itself bakes. Being neither a
function, nor a method, and absent explicit flagging as residing in
code space, ends up being considered data.
This patch marks the type as code when it is created, on the theory
that this is needed for all Hardvard architectures. I believe this
should make no difference on archs with flat address space. Testing
on x86-64 GNU/Linux shows no changes.
gdb/
2014-02-12 Pedro Alves <palves@redhat.com>
Kevin Buettner <kevinb@redhat.com>
* gnu-v3-abi.c (build_gdb_vtable_type): Return a type marked with
TYPE_INSTANCE_FLAG_CODE_SPACE.
Kevin Buettner, at
<https://sourceware.org/ml/gdb-patches/2014-02/msg00338.html>, writes,
re. rl78:
This patch, for rl78 using the default multilib, fixes 5 failures in
gdb.cp/casts.exp, 2 failures in gdb.cp/class2.exp, 115 failures in
gdb.mi/mi-var-rtti.exp, and 2 failures in gdb.python/py-value.exp.
It introduces 9 failures (regressions) in gdb.mi/mi-var-rtti.exp.
One of the regressions is:
FAIL: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
The relevant lines from the log file from a pre-patch test run are as
follows:
-var-list-children S.public
^done,numchild="1",children=[child={name="S.public.ptr",exp="ptr",numchild="1",type="Base *",thread-id="1"}],has_more="0"
(gdb)
PASS: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
Expecting: \^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"
Expecting: ^(-var-list-children S\.public\.ptr [
]+)?(\^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"[
]+[(]gdb[)]
[ ]*)
The same set of lines for the failing (post-patch) run are instead:
-var-list-children S.public
&"warning: can't find linker symbol for virtual table for `Base' value\n"
&"warning: found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
&"warning: can't find linker symbol for virtual table for `Base' value\n"
&"warning: found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
&"warning: can't find linker symbol for virtual table for `Base' value\n"
&"warning: found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
^done,numchild="1",children=[child={name="S.public.ptr",exp="ptr",numchild="1",type="Base *",thread-id="1"}],has_more="0"
(gdb)
FAIL: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
Expecting: \^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"
Expecting: ^(-var-list-children S\.public\.ptr [
]+)?(\^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"[
]+[(]gdb[)]
[ ]*)
Note that the difference between these are the warnings regarding
linker symbols. Aside from the warnings, the result is the same.
I.e. gdb produces the correct answer despite the warnings. The
reason for the other 8 failures is the same: the test harness is not
expecting these warnings.
I spent some time (a while ago) looking at the reason for these
warnings. As I recall, we are now getting further along in the type
resolution process than we were without my patch. I.e. for the
example above, the code in question never got to the point where it
was looking for the specified linker symbol. So it seems to me that,
at worst, my patch exposes some other problem, but is not directly the
cause of the problem.
'info registers ccr' corrupts memory.
Debugging gdb under Valgrind, we see:
(gdb) info registers ccr
==23225== Invalid write of size 1
==23225== at 0x4A0A308: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:881)
==23225== by 0x52D334: regcache_raw_read (regcache.c:625)
==23225== by 0x45E4D8: h8300_pseudo_register_read (h8300-tdep.c:1171)
==23225== by 0x5B694B: gdbarch_pseudo_register_read (gdbarch.c:1926)
==23225== by 0x52DADB: regcache_cooked_read (regcache.c:740)
==23225== by 0x52DC10: regcache_cooked_read_value (regcache.c:765)
==23225== by 0x68CA41: sentinel_frame_prev_register (sentinel-frame.c:52)
==23225== by 0x6B80CB: frame_unwind_register_value (frame.c:1105)
==23225== by 0x6B7C97: frame_register_unwind (frame.c:1010)
==23225== by 0x6B7F73: frame_unwind_register (frame.c:1064)
==23225== by 0x6B8359: frame_unwind_register_signed (frame.c:1162)
==23225== by 0x6B8396: get_frame_register_signed (frame.c:1169)
==23225== Address 0x4f7b031 is 0 bytes after a block of size 1 alloc'd
==23225== at 0x4A06B0F: calloc (vg_replace_malloc.c:593)
==23225== by 0x6EB754: xcalloc (common-utils.c:91)
==23225== by 0x6EB793: xzalloc (common-utils.c:101)
==23225== by 0x53A782: allocate_value_contents (value.c:854)
==23225== by 0x53A7B4: allocate_value (value.c:864)
==23225== by 0x52DBC8: regcache_cooked_read_value (regcache.c:757)
==23225== by 0x68CA41: sentinel_frame_prev_register (sentinel-frame.c:52)
==23225== by 0x6B80CB: frame_unwind_register_value (frame.c:1105)
==23225== by 0x6B7C97: frame_register_unwind (frame.c:1010)
==23225== by 0x6B7F73: frame_unwind_register (frame.c:1064)
==23225== by 0x6B8359: frame_unwind_register_signed (frame.c:1162)
==23225== by 0x6B8396: get_frame_register_signed (frame.c:1169)
==23225==
ccr 0x00 0 I-0 UI-0 H-0 U-0 N-0 Z-0 V-0 C-0 u> u>= != >= >
(gdb)
This bit:
==23225== Invalid write of size 1
==23225== at 0x4A0A308: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:881)
==23225== by 0x52D334: regcache_raw_read (regcache.c:625)
==23225== by 0x45E4D8: h8300_pseudo_register_read (h8300-tdep.c:1171)
shows the problem. The CCR pseudo register has type length of 1,
while the corresponding CCR raw register has a length of 2 or 4
(depending on mode). In
sim/h8300/compile.c:sim_{fetch|store}_register we see that the sim
also treats those raw registers (CCR/EXR) as 2 or 4 bytes length.
gdb/
2014-02-12 Pedro Alves <palves@redhat.com>
* h8300-tdep.c (pseudo_from_raw_register)
(raw_from_pseudo_register): New functions.
(h8300_pseudo_register_read, h8300_pseudo_register_write): Use
them.
Currently, printing the H8/300 ccr register when debugging with the
sim is broken:
(gdb) target sim
...
(gdb) load
...
(gdb) start
...
Breakpoint 1, foo (i=0x0 <foo>) at main.c:4
4 {
(gdb) info registers ccr
Register 13 is not available
'13' is the ccr pseudo-register. This pseudo-register provides an
8-bit view into the raw ccr register (regno=8).
The problem is that the H8/300 port does not define a
register_sim_regno gdbarch hook, and thus when fetching the raw
register off of the sim, we end up in legacy_register_sim_regno trying
to figure out the sim register number for the raw CCR register:
int
legacy_register_sim_regno (struct gdbarch *gdbarch, int regnum)
{
/* Only makes sense to supply raw registers. */
gdb_assert (regnum >= 0 && regnum < gdbarch_num_regs (gdbarch));
/* NOTE: cagney/2002-05-13: The old code did it this way and it is
suspected that some GDB/SIM combinations may rely on this
behavour. The default should be one2one_register_sim_regno
(below). */
if (gdbarch_register_name (gdbarch, regnum) != NULL
&& gdbarch_register_name (gdbarch, regnum)[0] != '\0')
return regnum;
else
return LEGACY_SIM_REGNO_IGNORE;
}
Because the raw ccr register does not have a name (so that it is
hidden from the user), that returns LEGACY_SIM_REGNO_IGNORE. That
means that we never actually read the value of the raw ccr register.
Before the <unavailable> support, this must have meant that ccr was
_always_ read as 0... At least, I'm not seeing how this ever worked.
The fix for that is adding a gdbarch_register_sim_regno hook that maps
all raw registers. Looking at sim/h8300/sim-main.h, I believe the
sim's register numbers are compatible with gdb's, so no actual
convertion is necessary.
gdb/
2014-02-12 Pedro Alves <palves@redhat.com>
* h8300-tdep.c (h8300_register_sim_regno): New function.
(h8300_gdbarch_init): Install h8300_register_sim_regno as
gdbarch_register_sim_regno hook.
Adding long-branch stubs for __tls_get_addr calls that are optimised
away is silly. It also causes assertion failures on newer object files
that use R_PPC_TLSGD and R_PPC_TLSLD marker relocs, and half-optimised
(ie. broken) code for older object files.
PR 16546
* elf32-ppc.c (ppc_elf_relax_section): Don't build long-branch
stubs for calls to __tls_get_addr that we know will later be
optimised away.
The Linux kernel builds modules using ld -r. These might need the
ppc476 workaround, so enable it for ld -r if sections have sufficient
alignment to tell location within a page.
bfd/
* elf32-ppc.c (ppc_elf_relax_section): Enable ppc476 workaround
for ld -r, when code sections are sufficiently aligned.
* elf32-ppc.h (struct ppc_elf_params): Delete pagesize. Add
pagesize_p2.
ld/
* emultempl/ppc32elf.em (pagesize): New static var.
(ppc_after_open_output): Set params.pagesize_p2 from pagesize.
(PARSE_AND_LIST_ARGS_CASES): Adjust to use pagesize.
