This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: extract_unsigned_integer API (Re: [PATCH] Remove MAX_REGISTER_SIZE from frame.c)


On 03/28/2017 05:57 PM, Pedro Alves wrote:

> Yes, and that can sorted by e.g., passing the size to the buffer()
> method, as I mentioned in the comment.  Like:
> 
>   extractor extr;
>   frame_unwind_register (frame, regnum, ext.buffer (size));
>   return extr.extract (size, byte_order);
> 
> extractor::buffer(size_t) would throw error on overflow.
> 
> Or pass it to the ctor (which would likewise throw error on overflow):
> 
>   extractor extr (size);
>   frame_unwind_register (frame, regnum, ext.buffer ());
>   return extr.extract (size, byte_order);
> 
> Could even store the size and byte order inside the extractor
> object, and avoid writing the size more than once:
> 
>   extractor extr (size, byte_order);
>   frame_unwind_register (frame, regnum, ext.buffer ());
>   return extr.extract ();
> 
> Or make "extrator::buffer" remember the last size, so extractors
> can be reused.  Or even support both, ctor with and without size,
> buffer() with and without size.  extractror::extract would always
> used the last remembered size.
> 
> So I still don't see any advantage in a callback-based interface.

Thinking about this a bit more, if we went this direction, I think the
simplest would be to add an extract::size() method that returned the
size of the buffer, and use that for bounds when filling in the
data, like:

   extractor extr;
   frame_unwind_register (frame, regnum, ext.buffer (), ext.size ());
   return extr.extract (type_len, byte_order);

If type_len is larger than the buffer size, then we'll still get an
error either inside extractor::extract, and maybe earlier
inside frame_unwind_register (if it had that size parameter).

Though for the particular case of frame_unwind_register, since the
frame machinery works with struct value's, inside frame_unwind_register
there's going to be a value created already, and that has a contents
buffer we could access directly.  So e.g.,
inside frame_unwind_register_signed, we should be able to use
frame_unwind_register_value directly thus avoid the need for the local
buffer and copying data.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]