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

Re: [PATCH 5/7] Add support for software single step on ARM aarch32-linux in GDBServer.

On 09/14/2015 12:10 PM, Yao Qi wrote:
Antoine Tremblay <> 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
data memory...

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.

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...

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 ?

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