FreeChainXenon/binutils-gdb
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

PR13858 - Can't do displaced stepping with no symbols

Browse source 
Running break-interp.exp with the target always in non-stop mode trips
on PR13858, as enabling non-stop also enables displaced stepping.

The problem is that when GDB doesn't know where the entry point is, it
doesn't know where to put the displaced stepping scratch pad.  The
test added by this commit exercises this.  Without the fix, we get:

 (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: break *$pc
 set displaced-stepping on
 (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: set displaced-stepping on
 stepi
 0x00000000004005be in ?? ()
 Entry point address is not known.
 (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: stepi
 p /x $pc
 $2 = 0x4005be
 (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: get after PC
 FAIL: gdb.base/step-over-no-symbols.exp: displaced=on: advanced

The fix switches all GNU/Linux ports to get the entry point from
AT_ENTRY in the target auxiliary vector instead of from symbols.  This
is currently only done by PPC when Cell debugging is enabled, but I
think all archs should be able to do the same.  Note that
ppc_linux_displaced_step_location cached the result, I'm guessing to
avoid constantly re-fetching the auxv out of remote targets, but
that's no longer necessary nowadays, as the auxv blob is itself cached
in the inferior object.  The ppc_linux_entry_point_addr global is
obviously bad for multi-process too nowadays.

Tested on x86-64 (-m64/-m32), PPC64 (-m64/-m32) and S/390 GNU/Linux.
Yao tested the new test on ARM as well.

gdb/ChangeLog:
2015-04-10  Pedro Alves  <palves@redhat.com>

	PR gdb/13858
	* amd64-linux-tdep.c (amd64_linux_init_abi_common): Install
	linux_displaced_step_location as gdbarch_displaced_step_location
	hook.
	* arm-linux-tdep.c (arm_linux_init_abi): Likewise.
	* i386-linux-tdep.c (i386_linux_init_abi): Likewise.
	* linux-tdep.c (linux_displaced_step_location): New function,
	based on ppc_linux_displaced_step_location.
	* linux-tdep.h (linux_displaced_step_location): New declaration.
	* ppc-linux-tdep.c (ppc_linux_entry_point_addr): Delete.
	(ppc_linux_inferior_created, ppc_linux_displaced_step_location):
	Delete.
	(ppc_linux_init_abi): Install linux_displaced_step_location as
	gdbarch_displaced_step_location hook, even without Cell/B.E..
	(_initialize_ppc_linux_tdep): Don't install
	ppc_linux_inferior_created as inferior_created observer.
	* s390-linux-tdep.c (s390_gdbarch_init): Install
	linux_displaced_step_location as gdbarch_displaced_step_location
	hook.

gdb/testsuite/
2015-04-10  Pedro Alves  <palves@redhat.com>

	PR gdb/13858
	* gdb.base/step-over-no-symbols.exp: New file.
This commit is contained in:
Pedro Alves 2015-04-10 10:07:02 +01:00
parent 8c3fff59dc
commit 906d60cf46
10 changed files with 162 additions and 54 deletions
Download patch file Download diff file Expand all files Collapse all files

31
gdb/linux-tdep.c
View file

@ -2348,6 +2348,37 @@ linux_infcall_mmap (CORE_ADDR size, unsigned prot)
return retval;
}
/* See linux-tdep.h. */
CORE_ADDR
linux_displaced_step_location (struct gdbarch *gdbarch)
{
CORE_ADDR addr;
int bp_len;
/* Determine entry point from target auxiliary vector. This avoids
the need for symbols. Also, when debugging a stand-alone SPU
executable, entry_point_address () will point to an SPU
local-store address and is thus not usable as displaced stepping
location. The auxiliary vector gets us the PowerPC-side entry
point address instead. */
if (target_auxv_search (&current_target, AT_ENTRY, &addr) <= 0)
error (_("Cannot find AT_ENTRY auxiliary vector entry."));
/* Make certain that the address points at real code, and not a
function descriptor. */
addr = gdbarch_convert_from_func_ptr_addr (gdbarch, addr,
&current_target);
/* Inferior calls also use the entry point as a breakpoint location.
We don't want displaced stepping to interfere with those
breakpoints, so leave space. */
gdbarch_breakpoint_from_pc (gdbarch, &addr, &bp_len);
addr += bp_len * 2;
return addr;
}
/* Display whether the gcore command is using the
/proc/PID/coredump_filter file. */