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

[Antoine Tremblay <antoine.tremblay@ericsson.com>]

On 09/14/2015 12:10 PM, Yao Qi wrote:
> Antoine Tremblay <antoine.tremblay@ericsson.com> writes:
>
>> Usually it will be , however see commit :
>> dcd4a3a4e7fc3912194d1346d2dfc6252f70b456
>>
>> 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
>>   form."
>>
>> 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
>> system.
>
> 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 ?