Re: Laziness

David Lecomber
2005-10-10T21:24:53Z

On Mon, 2005-10-10 at 17:09 -0400, Daniel Jacobowitz wrote:

>
> No, as they're read in, one at a time, and compared to the previous
> element.

Err, but I don't think they are. I should've included the top of my
stack:

#1 0x00b3cb1a in ptrace () from /lib/libc.so.6
#2 0x0809512a in child_xfer_memory (memaddr=3207201336,
myaddr=0xb5e49048 "", len=8000000, write=0, attrib=0x0,
target=0x8299460) at infptrace.c:437
#3 0x08095766 in child_xfer_partial (ops=0x8299460,
object=TARGET_OBJECT_MEMORY, annex=0x0,
readbuf=0xb5e49048 "", writebuf=0x0, offset=The value of variable
'offset' is distributed across several
locations, and GDB cannot access its value.

) at inftarg.c:541
#4 0x0807eaa7 in target_xfer_partial (ops=0x8299460,
object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0xb5e49048,
writebuf=0x0, offset=3207201336, len=The value of variable 'len' is
distributed across several
locations, and GDB cannot access its value.

) at target.c:863
#5 0x0807ec9f in xfer_using_stratum (object=TARGET_OBJECT_MEMORY,
annex=0x0, offset=3207201336, len=The value of variable 'len' is
distributed across several
locations, and GDB cannot access its value.

)
at target.c:950
#6 0x0807f37b in target_read_memory (memaddr=3207201336,
myaddr=0xb5e49048 "", len=8000000) at target.c:1000
#7 0x08084a5a in read_memory (memaddr=3207201336, myaddr=0xb5e49048 "",
len=8000000) at corefile.c:239
#8 0x080e2509 in value_fetch_lazy (val=0xb5e49008) at valops.c:515
#9 0x080dc4fb in value_contents_all (value=0xb5e49008) at value.c:331
#10 0x08167551 in c_value_print (val=0xb5e49008, stream=0x91ea940,
format=0, pretty=Val_pretty_default)
at c-valprint.c:596
#11 0x080eb0f4 in print_formatted (val=0xb5e49008, format=0, size=0,
stream=0x91ea940) at .././gdb/printcmd.c:335
#12 0x080eb776 in output_command (exp=0x91ea9a7 "x", from_tty=1)
at .././gdb/printcmd.c:985

That value_contents_all and massive read is happening a good few seconds
before we start doing the repeated elements comparison in
val_print_array_elements..

--
David Lecomber <david@lecomber.net>