daily update
[RFA] Stabs: Ignore N_BNSYM/N_ENSYM entry types

Trying to debug gdb with itself,
I stumbled on the following complaints
Unknown symbol type 0x2e
or
Unknown symbol type 0x4e

It appears that those corrspond to N_BNSYM and N_ENSYM,
which are MacOS extensions of stabs debugging format.
But these extensions have been used inside gcc probalby
for a while already, see:
https://gcc.gnu.org/ml/gcc/2004-08/msg00157.html

As the only purpose of these entries is to allow for removal
of stabs information if the function is removed,
it can be safely ignored by GDB.

This patch simply adds those two entry types to the list
of ignored entry type in read_dbx_symtab function.

Is this OK?

Pierre Muller

2014-10-03  Pierre Muller  <muller@sourceware.org>

	* dbxread.c (read_dbx_symtab): Also ignore N_BNSYM/N_ENSYM.
MIPS bit field failures in gdb.base/store.exp

On MIPS64 little endian, attempting an assignment to a bit field
that lives in a register yields the wrong result. It just corrupts
the data in the register depending on the specific position of the
bit field inside the structure.

FAIL: gdb.base/store.exp: f_1.j
FAIL: gdb.base/store.exp: f_1.k
FAIL: gdb.base/store.exp: F_1.i
FAIL: gdb.base/store.exp: F_1.j
FAIL: gdb.base/store.exp: F_1.k
FAIL: gdb.base/store.exp: f_2.j
FAIL: gdb.base/store.exp: f_2.k
FAIL: gdb.base/store.exp: F_2.i
FAIL: gdb.base/store.exp: F_2.j
FAIL: gdb.base/store.exp: F_2.k
FAIL: gdb.base/store.exp: f_3.j
FAIL: gdb.base/store.exp: f_3.k
FAIL: gdb.base/store.exp: F_3.i
FAIL: gdb.base/store.exp: F_3.j
FAIL: gdb.base/store.exp: F_3.k
FAIL: gdb.base/store.exp: f_4.j
FAIL: gdb.base/store.exp: f_4.k
FAIL: gdb.base/store.exp: F_4.i
FAIL: gdb.base/store.exp: F_4.j
FAIL: gdb.base/store.exp: F_4.k

                === gdb Summary ===

Now, GDB knows how to do bit field assignment properly, but MIPS is
one of those architectures that uses a hook for the register-to-value
conversion. Although we can properly tell when the type being passed
is a structure or union, we cannot tell when it is a bit field,
because the bit field data lives in a value structure.  Such data
only lives in a "type" structure when the parent structure is being
referenced, thus you can collect them from the flds_bnds members.

A bit field type structure looks pretty much the same as any other
primitive type like int or char, so we can't distinguish them.
Forcing more fields into the type structure wouldn't help much,
because the type structs are shared.

2014-10-03  Luis Machado  <lgustavo@codesourcery.com>

	* valops.c (value_assign): Check for bit field assignments
	before calling architecture-specific register value
	conversion functions.
Avoid software breakpoint's instruction shadow inconsistency

This change:

commit b775012e845380ed4c7421a1b87caf7bfae39f5f
Author: Luis Machado <luisgpm@br.ibm.com>
Date:   Fri Feb 24 15:10:59 2012 +0000

    2012-02-24  Luis Machado  <lgustavo@codesourcery.com>

	* remote.c (remote_supports_cond_breakpoints): New forward
	declaration.
[...]

changed the way breakpoints are inserted and removed such that
`insert_bp_location' can now be called with the breakpoint being handled
already in place, while previously the call was only ever made for
breakpoints that have not been put in place.  This in turn caused an
issue for software breakpoints and targets for which a breakpoint's
`placed_address' may not be the same as the original requested address.

The issue is `insert_bp_location' overwrites the previously adjusted
value in `placed_address' with the original address, that is only
replaced back with the correct adjusted address later on when
`gdbarch_breakpoint_from_pc' is called.  Meanwhile there's a window
where the value in `placed_address' does not correspond to data stored
in `shadow_contents', leading to incorrect instruction bytes being
supplied when `one_breakpoint_xfer_memory' is called to supply the
instruction overlaid by the breakpoint.

And this is exactly what happens on the MIPS target with software
breakpoints placed in microMIPS code.  In this case not only
`placed_address' is not the original address because of the ISA bit, but
`mips_breakpoint_from_pc' has to read the original instruction to
determine which one of the two software breakpoint instruction encodings
to choose as well.  The 16-bit encoding is used to replace 16-bit
instructions and similarly the 32-bit one is used with 32-bit
instructions, to satisfy branch delay slot size requirements.

The mismatch between `placed_address' and the address data in
`shadow_contents' has been obtained from leads to the wrong encoding
being used in some cases, which in the case of a 32-bit software
breakpoint instruction replacing a 16-bit instruction causes corruption
to the adjacent following instruction and leads the debug session astray
if execution reaches there e.g. with a jump.

To address this problem I made the change below, that adds a
`reqstd_address' field to `struct bp_target_info' and leaves
`placed_address' unchanged once it has been set.  This ensures data in
`shadow_contents' is always consistent with `placed_address'.

This approach also has this good side effect that all the places that
examine the breakpoint's address see a consistent value, either
`reqstd_address' or `placed_address', as required.  Currently some
places see either the original or the adjusted address in
`placed_address', depending on whether they have been called before
`gdbarch_remote_breakpoint_from_pc' or afterwards.  This is in
particular true for subsequent calls to
`gdbarch_remote_breakpoint_from_pc' itself, e.g. from
`one_breakpoint_xfer_memory'.  This is also important for places like
`find_single_step_breakpoint' where a breakpoint's address is compared
to the raw value of $pc.

	* breakpoint.h (bp_target_info): Add `reqstd_address' member,
	update comments.
	* breakpoint.c (one_breakpoint_xfer_memory): Use `reqstd_address'
	for the breakpoint's address.  Don't preinitialize `placed_size'.
	(insert_bp_location): Set `reqstd_address' rather than
	`placed_address'.
	(bp_target_info_copy_insertion_state): Also copy `placed_address'.
	(bkpt_insert_location): Use `reqstd_address' for the breakpoint's
	address.
	(bkpt_remove_location): Likewise.
	(deprecated_insert_raw_breakpoint): Likewise.
	(deprecated_remove_raw_breakpoint): Likewise.
	(find_single_step_breakpoint): Likewise.
	* mem-break.c (default_memory_insert_breakpoint): Use
	`reqstd_address' for the breakpoint's address.  Don't set
	`placed_address' or `placed_size' if breakpoint contents couldn't
	have been determined.
	* remote.c (remote_insert_breakpoint): Use `reqstd_address' for
	the breakpoint's address.
	(remote_insert_hw_breakpoint): Likewise.  Don't set
	`placed_address' or `placed_size' if breakpoint couldn't have been
	set.
	* aarch64-linux-nat.c (aarch64_linux_insert_hw_breakpoint): Use
	`reqstd_address' for the breakpoint's address.
	* arm-linux-nat.c (arm_linux_hw_breakpoint_initialize): Likewise.
	* ia64-tdep.c (ia64_memory_insert_breakpoint): Likewise.
	* m32r-tdep.c (m32r_memory_insert_breakpoint): Likewise.
	* microblaze-linux-tdep.c
	(microblaze_linux_memory_remove_breakpoint): Likewise.
	* monitor.c (monitor_insert_breakpoint): Likewise.
	* nto-procfs.c (procfs_insert_breakpoint): Likewise.
	(procfs_insert_hw_breakpoint): Likewise.
	* ppc-linux-nat.c (ppc_linux_insert_hw_breakpoint): Likewise.
	* ppc-linux-tdep.c (ppc_linux_memory_remove_breakpoint): Likewise.
	* remote-m32r-sdi.c (m32r_insert_breakpoint): Likewise.
	* remote-mips.c (mips_insert_breakpoint): Likewise.
	* x86-nat.c (x86_insert_hw_breakpoint): Likewise.
Also mark ELF solib trampoline minimal symbols special

In installing minimal symbols for ELF shared library trampolines
we "forget" to make individual symbols special where required.  This
leads to problems on the MIPS target using microMIPS SVR4 lazy stubs.
Lacking the special annotation these stubs are treated as standard
MIPS code and this makes GDB insert the wrong software breakpoint
instruction, breaking e.g. single-stepping through these stubs.  This
is not a very frequent scenario as microMIPS SVR4 lazy stubs are
typically only used in shared libraries with the main executable
using PLT, handled elsewhere.  Still it triggers e.g. when a software
watchpoint has been installed.  The symptom is SIGILL or the program
going astray, depending on the endianness.  Disassembly of these stubs
is also wrong.

	* elfread.c (elf_symtab_read): Also mark solib trampoline minimal
	symbols special.