This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Building solib-target.c when CORE_ADDR != ULONGEST.
On Sun, Jul 08, 2007 at 03:32:02PM +0100, Pedro Alves wrote:
> About the VEC in question. I noticed that the xml parsing
> xmalloc's the memory for the ULONGEST, but it is safe to
> pass a pointer in a local var, right?
Yes, that's right. The patch is OK.
> I got confused because in vec.h:
>
> "Because of the different behavior of structure objects, scalar
> objects and of pointers, there are three flavors, one for each of
> these variants. Both the structure object and pointer variants
> pass pointers to objects around -- in the former case the pointers
> are stored into the vector and in the latter case the pointers are
> dereferenced and the objects copied into the vector. The scalar
> object variant is suitable for int-like objects, and the vector
> elements are returned by value. "
>
> Something in there confuses me. The former/latter type of
> descriptions adds an indirection that I always find
> distracting.
Far as I can tell, Nathan got his formers and his latters crossed, and
that's why it doesn't make sense.
It would have made more sense for me to use DEF_VEC_I for these than
the DEF_VEC_O I actually used, but to be honest I didn't realize it
was there. The use of DEF_VEC_O makes this rather more confusing
than necessary.
> The 'by value' statement isn't clear to me either:
> "object variant is suitable for int-like objects, and the vector
> elements are returned by value. "
>
> T *VEC_T_index(VEC(T) *v, unsigned ix); // Object
>
> ? What does 'by value' mean then?
The previous word is "scalar". Scalar object -> integer, not
structure object. So the last bit of your correction is wrong.
> 2007-07-08 Pedro Alves <pedro_alves@portugalmail.pt>
>
> * solib-target.c (library_list_start_segment): Cast address to CORE_ADDR.
OK.
--
Daniel Jacobowitz
CodeSourcery