This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH 0/6] x32: Fast tracepoints support


Yesterday I installed an Ubuntu 16.04 virtual machine here, and
installed the x32 runtime support (basically, run "apt-cache search
x32", and install all that shows).  That made it easy to fix a few
basic x32 problems, the result of which were yesterday's x32 patches.

There's still one remaining annoying x32 problem however.  Even though
gdb and gdbserver build fine on x32 now, the build still fails, when
building the fast tracepoints in-process agent DSO (IPA), with:

   .../src/gdb/gdbserver/linux-amd64-ipa.c: In function ‘const target_desc* get_ipa_tdesc(int)’:
   .../src/gdb/gdbserver/linux-amd64-ipa.c:182:14: error: ‘tdesc_amd64_avx_linux’ was not declared in this scope
	  return tdesc_amd64_avx_linux;
		 ^
  [...]

So I took a stab at fixing it.  And then I thought I'd run the fast
tracepoint tests against the result.  And that showed a few problems,
all fixed by this series...

A diff of testing with:
 RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/*.exp"
vs 
 RUNTESTFLAGS="--target_board=native-gdbserver/-mx32" TESTS="gdb.trace/*.exp"

Shows that x32 support is just as good as 64-bit.  Actually, it's
better, since fast tracepoints on shared libraries work.  E.g.:

 -PASS: gdb.trace/change-loc.exp: 1 ftrace: continue to marker 2 (too far)
 +PASS: gdb.trace/change-loc.exp: 1 ftrace: continue to marker 2
 +PASS: gdb.trace/change-loc.exp: 1 ftrace: tracepoint with three locations
 +PASS: gdb.trace/change-loc.exp: 1 ftrace: continue to marker 3
 +PASS: gdb.trace/change-loc.exp: 1 ftrace: tracepoint with two locations - installed (unload)
 +PASS: gdb.trace/change-loc.exp: 1 ftrace: tracepoint with two locations - pending (unload)
 +PASS: gdb.trace/change-loc.exp: 1 ftrace: tstop
 +PASS: gdb.trace/change-loc.exp: 1 ftrace: tfind frame 0
 +PASS: gdb.trace/change-loc.exp: 1 ftrace: tfind

I didn't bother to save a few bytes by making the jump pad,
gdbserver's agent bytecode JIT etc. use/emit shorter instructions that
use 32-bit operands in the places where that would be possible on x32.
Not that it'd be complicated, it's just that I've already invested
more time in this at this point than I wanted, and that I'm assuming
that it wouldn't result in a significant optimization.  I'd be glad to
be proven wrong though, if someone wants to try that out.

Pedro Alves (6):
  x32 Fast tracepoints: IPA target descriptions
  x32 Fast tracepoints: Customize jump pad address
  x32: Avoid unsigned long when installing fast tracepoint jump pads
  x32: gdbserver's agent bytecode JIT: fix "call" emission
  x32: gdb: Fix 'call' insn relocation with qRelocInsn
  x32: Fix gdb.trace/mi-trace-frame-collected.exp

 gdb/amd64-tdep.c                                   | 42 ++++++++++--
 gdb/gdbserver/Makefile.in                          |  9 +++
 gdb/gdbserver/configure                            | 31 +++++++++
 gdb/gdbserver/configure.ac                         | 14 ++++
 gdb/gdbserver/configure.srv                        |  8 ++-
 gdb/gdbserver/linux-amd64-ipa.c                    | 79 +++++++++++++++++++---
 gdb/gdbserver/linux-x86-low.c                      |  8 ++-
 .../gdb.trace/mi-trace-frame-collected.exp         | 14 +++-
 8 files changed, 186 insertions(+), 19 deletions(-)

-- 
2.5.5


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]