From: Jonathan Larmour <jifl@eCosCentric.com>
To: Terry Guo <terry.guo@arm.com>
Cc: gdb-patches@sourceware.org, Joey Ye <Joey.Ye@arm.com>,
Matthew Gretton-Dann <Matthew.Gretton-Dann@arm.com>
Subject: Re: Fwd: Re: [patch] Add support for ARMv7M devices.
Date: Mon, 16 Apr 2012 14:40:00 -0000 [thread overview]
Message-ID: <4F8C2C53.8070306@eCosCentric.com> (raw)
In-Reply-To: <001c01cd1ba6$44a2bf50$cde83df0$@guo@arm.com>
On 16/04/12 08:55, Terry Guo wrote:
>
> Can somebody please tell me how the "guess" mechanism works? How can the
> buf_len in function process_g_packet become correct with "guess"?
Have a look at remote_read_description(), which is called early on when
connecting to the target. Once the target description (tdesc) is set from
there, subsequent calls to process_g_packet() will have an appropriate
value for sizeof_g_packet.
> Can we just make the arm-with-m.xml always include unnamed FPA registers? So
> that it can cope with the case with or without FPA registers.
I think that it might have been possible to arrange this if the FPA
registers happened to be sent at the very end of the "normal" register set
(courtesy of some handling in process_g_packet() of smaller 'g' packets).
But i don't think that's possible here given the FPA regs come after the
PC but before the XPSR at the end; at least not without adding much more
machinery somewhere, including extending the target description syntax. I
might be wrong though, as I don't know the ins-and-outs of this code as
well as others here.
Jifl
--
eCosCentric Limited http://www.eCosCentric.com/ The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
** Visit us at NEW:UK - the UK Embedded & Electronics Exhibition **
** ARM Partner Pavilion/Stand #114. 18-19 April. Birmingham NEC **
------["Si fractum non sit, noli id reficere"]------ Opinions==mine
next prev parent reply other threads:[~2012-04-16 14:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-09 4:25 Jonathan Larmour
2012-03-09 11:44 ` Pedro Alves
2012-03-09 15:53 ` Jonathan Larmour
2012-03-09 16:06 ` Pedro Alves
2012-04-16 7:56 ` Terry Guo
2012-04-16 14:40 ` Jonathan Larmour [this message]
2012-04-17 4:06 ` Terry Guo
2012-03-09 15:39 ` Yao Qi
2012-03-09 16:13 ` Jonathan Larmour
2012-03-09 16:29 ` Pedro Alves
2012-03-11 3:37 ` Jonathan Larmour
2012-03-14 16:06 ` Pedro Alves
2012-03-15 6:27 ` Jonathan Larmour
2012-03-15 17:09 ` Pedro Alves
2012-03-15 18:33 ` Jonathan Larmour
2012-03-15 18:43 ` Pedro Alves
2012-03-15 18:56 ` Jonathan Larmour
2012-03-15 18:58 ` Pedro Alves
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=4F8C2C53.8070306@eCosCentric.com \
--to=jifl@ecoscentric.com \
--cc=Joey.Ye@arm.com \
--cc=Matthew.Gretton-Dann@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=terry.guo@arm.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