From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Clear *VAL in regcache_raw_read_unsigned
Date: Thu, 11 Feb 2016 15:51:00 -0000 [thread overview]
Message-ID: <56BCAE02.7030803@redhat.com> (raw)
In-Reply-To: <864mdfp9b3.fsf@gmail.com>
On 02/11/2016 03:15 PM, Yao Qi wrote:
> I think this is better than 'make gdbserver use extract_unsigned_integer',
> which looks overkill to me.
I think it's only going to bite us back in the future.
From the perspective of potentially making it easier to share more
code between gdb and gdbserver, I'd prefer that. Would you object it?
>
>>
>> Or maybe better, just byte the bullet and make gdbserver use
>> extract_unsigned_integer, like gdb.
>>
>> The problem with that is that gdbserver can't currently use 'enum bfd_endian',
>> which IIRC, was already an issue in the get-next-pcs stuff. I've attached a
>
> get-next-pcs stuff needs endianness in GDB side. In GDBserver,
> endianness is not needed.
The get-next-pcs stuff does have endianness bits, but it works
around the lack of 'enum bfd_endian' by hacking it through an int instead:
void
arm_get_next_pcs_ctor (struct arm_get_next_pcs *self,
struct arm_get_next_pcs_ops *ops,
int byte_order,
int byte_order_for_code,
int has_thumb2_breakpoint,
struct regcache *regcache)
{
$ grep byte_order *
arm-get-next-pcs.c: int byte_order,
arm-get-next-pcs.c: int byte_order_for_code,
arm-get-next-pcs.c: self->byte_order = byte_order;
arm-get-next-pcs.c: self->byte_order_for_code = byte_order_for_code;
arm-get-next-pcs.c: int byte_order_for_code = self->byte_order_for_code;
arm-get-next-pcs.c: insn1 = self->ops->read_mem_uint (loc, 2, byte_order_for_code);
arm-get-next-pcs.c: insn2 = self->ops->read_mem_uint (loc, 2, byte_order_for_code);
arm-get-next-pcs.c: insn1 = self->ops->read_mem_uint (loc, 2,byte_order_for_code);
arm-get-next-pcs.c: insn2 = self->ops->read_mem_uint (loc, 2, byte_order_for_code);
arm-get-next-pcs.c: int byte_order_for_code = self->byte_order_for_code;
arm-get-next-pcs.c: insn = self->ops->read_mem_uint (loc, 4, byte_order_for_code);
arm-get-next-pcs.c: insn = self->ops->read_mem_uint (loc, 4, byte_order_for_code);
arm-get-next-pcs.c: int byte_order = self->byte_order;
arm-get-next-pcs.c: int byte_order_for_code = self->byte_order_for_code;
arm-get-next-pcs.c: inst1 = self->ops->read_mem_uint (pc, 2, byte_order_for_code);
arm-get-next-pcs.c: inst1 = self->ops->read_mem_uint (pc, 2,byte_order_for_code);
arm-get-next-pcs.c: inst1 = self->ops->read_mem_uint (pc, 2, byte_order_for_code);
arm-get-next-pcs.c: inst1 = self->ops->read_mem_uint (pc, 2, byte_order_for_code);
arm-get-next-pcs.c: nextpc = self->ops->read_mem_uint (sp + offset, 4, byte_order);
arm-get-next-pcs.c: inst2 = self->ops->read_mem_uint (pc + 2, 2, byte_order_for_code);
arm-get-next-pcs.c: nextpc = self->ops->read_mem_uint (addr + offset, 4, byte_order);
arm-get-next-pcs.c: = self->ops->read_mem_uint (base, 4, byte_order);
arm-get-next-pcs.c: length = 2 * self->ops->read_mem_uint (table + offset, 1, byte_order);
arm-get-next-pcs.c: length = 2 * self->ops->read_mem_uint (table + offset, 2, byte_order);
arm-get-next-pcs.c: int byte_order = self->byte_order;
arm-get-next-pcs.c: int byte_order_for_code = self->byte_order_for_code;
arm-get-next-pcs.c: this_instr = self->ops->read_mem_uint (pc, 4, byte_order_for_code);
arm-get-next-pcs.c: 4, byte_order);
arm-get-next-pcs.c: 4, byte_order);
arm-get-next-pcs.h: ULONGEST (*read_mem_uint) (CORE_ADDR memaddr, int len, int byte_order);
arm-get-next-pcs.h: int byte_order;
arm-get-next-pcs.h: int byte_order_for_code;
arm-get-next-pcs.h: int byte_order,
arm-get-next-pcs.h: int byte_order_for_code,
>
>> patch series that handles that by moving bfd_endian to a separate header.
>> I've pushed it to the users/palves/gdbserver-extract-unsigned-integer branch
>> as well.
>>
>> If you agree with this, I'll run the bfd_endian patch by the binutils folks.
>
> Since the endianness of GDBserver is always identical to the endianness
> of the program, I am not sure sharing extract_unsigned_integer between
> GDB and GDBserver is necessary.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2016-02-11 15:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-09 14:54 Yao Qi
2016-02-10 16:45 ` Yao Qi
2016-02-10 16:52 ` Pedro Alves
2016-02-10 17:25 ` Yao Qi
2016-02-10 17:36 ` Pedro Alves
2016-02-11 10:12 ` Yao Qi
2016-02-11 12:46 ` Pedro Alves
2016-02-11 15:15 ` Yao Qi
2016-02-11 15:51 ` Pedro Alves [this message]
2016-02-11 16:32 ` Antoine Tremblay
2016-02-11 17:00 ` Yao Qi
2016-02-11 17:24 ` Pedro Alves
2016-02-12 11:15 ` Yao Qi
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=56BCAE02.7030803@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=qiyaoltc@gmail.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