Re: Your change breaks GDB for ARM

[Richard Earnshaw <rearnsha at arm dot com>]

> A not so trivial find/grep shows:
> 
> cagney@nettle$ frep target_byte_order
> arch-utils.c:376:/* ``target_byte_order'' is only used when non- multi-arch.
> arch-utils.c:383:static int target_byte_order = BFD_ENDIAN_BIG;
> arch-utils.c:384:static int target_byte_order_auto = 1;
> arch-utils.c:389:  if (target_byte_order_auto)
> arch-utils.c:392:    return target_byte_order;
> arch-utils.c:412:  if (target_byte_order_auto)
> arch-utils.c:425:      target_byte_order_auto = 1;
> arch-utils.c:430:      target_byte_order_auto = 0;
> arch-utils.c:439:      target_byte_order_auto = 0;
> arch-utils.c:730:      && !target_byte_order_auto
> 
> which are all perfectly fine.  As for:
> 
> remote-rdp.c:355:                   target_byte_order = BFD_ENDIAN_LITTLE;
> remote-rdp.c:359:                   target_byte_order = BFD_ENDIAN_BIG;
> 
> oops, missed them.  I guess I could #ifdef them out (richard?).  Those 
> assignments haven't done anything useful since 2002-02-08 when the arm 
> became multi-arch partial.

Erm, maybe.  When you open a remote target via RDP you get the option to 
ask the target to set the endianness (or you can ask "tell me your 
endianness").  If you select an endianness and it isn't supported, you 
should get back the error RDIError_WrongByteSex; if you ask it to tell 
you, it will report back either RDIError_BigEndian or 
RDIError_LittleEndian.  The idea is to allow the board to tell you what it 
can support.

What should be done will depend on when we open the connection to the 
board.  If it's after we've selected an image to send, then we should pass 
the endianness of the image in the initial connection.  If it's before, 
then we should ask the board.  I think the best solution is to delay 
connecting to the target until we have an image if possible.  That avoids 
the situation where we have a target that is bi-endian (eg a simulator -- 
most boards are fixed-endian) and it reports the one we don't want -- 
there's no way for the remote end to say "I'm currently foo, but I can 
also to bar".

R.