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.
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
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. */