This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 5/7] Add support for software single step on ARM aarch32-linux in GDBServer.
- From: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Mon, 14 Sep 2015 13:28:15 -0400
- Subject: Re: [PATCH 5/7] Add support for software single step on ARM aarch32-linux in GDBServer.
- Authentication-results: sourceware.org; auth=none
- References: <1441973603-15247-1-git-send-email-antoine dot tremblay at ericsson dot com> <1441973603-15247-6-git-send-email-antoine dot tremblay at ericsson dot com> <8637yh5kpz dot fsf at gmail dot com> <55F6C071 dot 1040104 at ericsson dot com> <86twqx3rty dot fsf at gmail dot com>
On 09/14/2015 12:10 PM, Yao Qi wrote:
Antoine Tremblay <email@example.com> writes:
Usually it will be , however see commit :
Which I will partially quote here :
"tdep->arm_breakpoint, tdep->thumb_breakpoint, tdep->thumb2_breakpoint
should be set le_ variants in case of arm BE8 code. Those instruciton
sequences are writen to target with simple write_memory, without
regarding gdbarch_byte_order_for_code. But in BE8 case even data
memory is in big endian form, instructions are still in little endian
So in BE8 code the instructions are not of the same endianness as the
Do you want to support BE8 in GDBserver in your patches? If yes, please
split them out of your patch set. Current GDBserver doesn't consider
the difference of data endianness and instruction endianness, so you
don't have to worry about it too much, unless you really want to fix
problems on this.
Well my goal is to have feature parity between GDB and GDBServer as much
as possible, so yes I would like to support BE8 in GDBServer.
Since BE8 support entails endianness awareness I can't split them out
logically based on the BE8 feature, that would be writing the breakpoint
handling code code without endianness support and then rewriting it
completely with a patch labeled BE8 that would teach endianness to these
features. This would be a major overhead with no value imho.
Maybe I misunderstood what you meant ?
I think it's better to include endianness awareness in GDBServer from
patch1 and not redo the work. In that case BE8 support becomes only 1
variable in a function and thus does not need it's own patch.
Me neither but I would say it's a matter of context and that if
supporting it is easy and needed by another feature anyway, why not ?
Also even if unlikely you could have a BE program being debugged in a
LE GDBServer assuming the proper BE libs are also present on the
I don't think it is practical to do so...