From: Richard Earnshaw <rearnsha@arm.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: Phil Edwards <phil@jaj.com>, Richard Earnshaw <rearnsha@arm.com>,
gdb@sources.redhat.com
Subject: Re: Your change breaks GDB for ARM
Date: Fri, 21 Nov 2003 16:49:00 -0000 [thread overview]
Message-ID: <200311211649.hALGnRt02516@pc960.cambridge.arm.com> (raw)
In-Reply-To: Your message of "Fri, 21 Nov 2003 11:30:58 EST." <3FBE3DC2.8030007@redhat.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.
next prev parent reply other threads:[~2003-11-21 16:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-21 7:55 Phil Edwards
2003-11-21 16:31 ` Andrew Cagney
2003-11-21 16:49 ` Richard Earnshaw [this message]
2003-11-21 18:04 ` Andrew Cagney
2003-11-23 10:48 ` Phil Edwards
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200311211649.hALGnRt02516@pc960.cambridge.arm.com \
--to=rearnsha@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=ac131313@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=phil@jaj.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox