Re: Building solib-target.c when CORE_ADDR != ULONGEST.

[Pedro Alves <pedro_alves@portugalmail.pt>]

[-- Attachment #1: Type: text/plain, Size: 2733 bytes --]

Daniel Jacobowitz wrote:
> On Sun, Jul 08, 2007 at 02:20:49AM +0100, Pedro Alves wrote:
>> I'm using the attached patch to try to catch invalid data send by a
>> (remote) target, but I guess it isn't correct for all archs.
> 
> I don't think this check is worth doing, honestly.  Does it work fine
> with just the cast?
> 

Sure.  I used it to double check gdbserver was passing right
values, and I agree that it is overkill.

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?

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.

Here:

"in the latter case the pointers are dereferenced and the objects
copied into the vector."

... is it talking about the latter from the immediately previous sentence ?:

"Both the structure object and pointer variants pass pointers
to objects around"
Seems strange if so.

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?

How about this, it is right?

      "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.
       The pointer variant simply stores pointer directly in the vector.
       In the structure object variant, the pointers are dereferenced
       and the objects copied into the vector.  In this variant, the
       vector elements are returned by value, making it suitable for
       int-like objects.  "

I understood it as if they were analogous of:

struct type;
pointer -> std::vector<type*>
object -> std::vector<type>
integral -> std::vector<int>

I guess I'm pretty much confused.  :(

Attached is a new patch.  Tested that shreloc.exp still passes
all the tests on WinCE, testing from a Cygwin host.

Cheers,
Pedro Alves


[-- Attachment #2: solib-target_CORE_ADDR_cast.diff --]
[-- Type: text/x-diff, Size: 902 bytes --]

2007-07-08  Pedro Alves  <pedro_alves@portugalmail.pt>

	* solib-target.c (library_list_start_segment): Cast address to CORE_ADDR.

---
 gdb/solib-target.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: src/gdb/solib-target.c
===================================================================
--- src.orig/gdb/solib-target.c	2007-07-08 02:04:24.000000000 +0100
+++ src/gdb/solib-target.c	2007-07-08 12:19:12.000000000 +0100
@@ -82,8 +82,9 @@ library_list_start_segment (struct gdb_x
   VEC(lm_info_p) **list = user_data;
   struct lm_info *last = VEC_last (lm_info_p, *list);
   ULONGEST *address_p = VEC_index (gdb_xml_value_s, attributes, 0)->value;
+  CORE_ADDR address = (CORE_ADDR) *address_p;
 
-  VEC_safe_push (CORE_ADDR, last->segment_bases, address_p);
+  VEC_safe_push (CORE_ADDR, last->segment_bases, &address);
 }
 
 /* Handle the start of a <library> element.  */