This is the mail archive of the gdb-testers@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]

[binutils-gdb] Map registers to remote numbers when encoding an ax_reg or ax_reg_mask operation


*** TEST RESULTS FOR COMMIT 1eb7c2d886c0faac42d2b68862b0e6b0d3182d98 ***

Author: Antoine Tremblay <antoine.tremblay@ericsson.com>
Branch: master
Commit: 1eb7c2d886c0faac42d2b68862b0e6b0d3182d98

Map registers to remote numbers when encoding an ax_reg or ax_reg_mask operation

When encoding the agent expression operation ax_reg or ax_reg_mask, the
register number used is internal to GDB. However GDBServer expects a tdesc
based number.

This usually does not cause a problem since at the moment, for raw
registers GDBServer R trace action ignores the register mask and just
collects all registers.

It can be a problem, however with pseudo registers on some platforms if the
tdesc number doesn't match the GDB internal register number.

This is the case with ARM, the upcoming ARM tracepoint support, fails
these test cases without this patch:

gdb.trace/collection.exp: collect register locals collectively:*

GDBSever would exit with: unhandled register size
Since the register number is not mapped.

This patch fixes these issues by calling gdbarch_remote_register_number
before encoding the register number in the ax_reg or ax_reg_mask operation.

Tested on x86 native-gdbserver no regressions observed.

gdb/ChangeLog:

	* ax-general.c (ax_reg): Call gdbarch_remote_register_number.
	(ax_reg_mask): Likewise.


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