This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug server/13392] JMP insn in jump pad is not correct when offsetexceeds integer limit
- From: "qiyao at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 08 Nov 2011 04:09:17 +0000
- Subject: [Bug server/13392] JMP insn in jump pad is not correct when offsetexceeds integer limit
- Auto-submitted: auto-generated
- References: <bug-13392-4717@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13392
--- Comment #1 from Yao Qi <qiyao at gcc dot gnu.org> 2011-11-08 04:09:17 UTC ---
I tried to fix this problem in different ways,
#1. Choose absolute indirect jump along with a trampoline, however, absolute
indirect jump is 6-byte long, so that means the insn set that we can use fast
tracepoint is smaller.
#2. Return 1 (error) if offset exceeds the 4-byte limit. This makes
inconsistency of gdb and gdbserver when error happens, because gdb does not
know this error. So far, the offset from original insn to jump pad is got
during installing tracepoint rather than downloading tracepoint, so it is too
late when gdbserver finds that offset is too long. We can call qRelocInsn when
dowloading tracepoint, check offset, if offset is OK, cache result of
qRelocInsn, otherwise reply error. This requires more changes, I'll revisit
this later.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.