This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 2/3] Allocate data in cached_reg_t
- From: Luis Machado <lgustavo at codesourcery dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: Alan Hayward <Alan dot Hayward at arm dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, nd <nd at arm dot com>
- Date: Tue, 10 Jan 2017 11:42:19 -0600
- Subject: Re: [PATCH 2/3] Allocate data in cached_reg_t
- Authentication-results: sourceware.org; auth=none
- References: <3BD71BF1-BD32-4952-9E54-8FD14EB54987@arm.com> <firstname.lastname@example.org> <20170110125905.GF9518@E107787-LIN>
- Reply-to: Luis Machado <lgustavo at codesourcery dot com>
On 01/10/2017 06:59 AM, Yao Qi wrote:
On 17-01-09 14:11:13, Luis Machado wrote:
@@ -6306,7 +6306,7 @@ remote_console_output (char *msg)
typedef struct cached_reg
- gdb_byte data[MAX_REGISTER_SIZE];
+ gdb_byte *data;
Would it make sense to go C++ and use a data structure that can take
care of variable sizes? Just thinking if that would be easier than
handling allocation/deallocation of the data.
Do you suggest std::vector? We still need to allocate/deallocate it
if we change "gdb_byte *data" to "std::vector<gdb_byte> *data", or we
have to convert cached_reg to class, and do RAII.
Something like std::vector, yes. But it is true we will still need to
allocate the vector itself.
I was pondering about the benefits of not being limited to a specific
register size. Then we wouldn't need to worry about adjusting things as
we have to do now.
As i see it, data[register_size(register_size (gdbarch, num)] wouldn't
be much different than data[MAX_REGISTER_SIZE]. The only thing is that
we're setting the max register size dynamically.
We may or may not need this flexibility right now, but who knows what
weird architectures we may have in the future.