Re: [RFC][patch] Make DCACHE_LINE runtime-settable

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Mon, Jul 25, 2011 at 12:00 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:

> I was tweaking the LINE_SIZE_POWER facing this problem in mail:
> ? ? ? ?https://fedorahosted.org/pipermail/crash-catcher/2010-December/001441.html
>
> I have seen some of the target_read_memory requests are needlessly fragmented
> into LINE_SIZE_POWER sized read requests. ?Have you considered making the
> gdbserver protocol read requests size dynamic depending on the caller's
> requested read size?

Uhm. The caller read request size here is 8 bytes (else I didn't
understand what you are suggesting):

#0  dcache_xfer_memory (ops=0xd34ec0, dcache=0xd647a0,
                        memaddr=140737234392872, myaddr=0x4719b30 "",
                        len=8, should_write=0) at ../../src/gdb/dcache.c:496
#1  0x00000000005eaba3 in memory_xfer_partial (ops=0xd34ec0,

object=TARGET_OBJECT_STACK_MEMORY,
                                               readbuf=0x4719b30,
                                               writebuf=0x0,
                                               memaddr=140737234392872,
                                               len=8) at
                                               ../../src/gdb/target.c:1522
#2  0x00000000005eae72 in target_xfer_partial (ops=0xd34ec0,

object=TARGET_OBJECT_STACK_MEMORY,
                                               annex=0x0, readbuf=0x4719b30,
                                               writebuf=0x0,
                                               offset=140737234392872, len=8)
                                               at ../../src/gdb/target.c:1625
#3  0x00000000005eb6cc in target_read_partial (ops=0xd34ec0,

object=TARGET_OBJECT_STACK_MEMORY,
                                               annex=0x0, buf=0x4719b30 "",
                                               offset=140737234392872, len=8)
                                               at ../../src/gdb/target.c:1904
#4  0x00000000005eb796 in target_read (ops=0xd34ec0,
                                       object=TARGET_OBJECT_STACK_MEMORY,
                                       annex=0x0, buf=0x4719b30 "",
                                       offset=140737234392872, len=8)
                                       at ../../src/gdb/target.c:1930
#5  0x00000000005eb121 in target_read_stack (memaddr=140737234392872,
                                             myaddr=0x4719b30 "", len=8)
                                             at ../../src/gdb/target.c:1719
#6  0x0000000000475c21 in read_stack (memaddr=140737234392872,
                                      myaddr=0x4719b30 "", len=8) at
                                      ../../src/gdb/corefile.c:252
#7  0x000000000057392b in read_value_memory (val=0x8f52b20,
                                             embedded_offset=0, stack=1,
                                             memaddr=140737234392872,
                                             buffer=0x4719b30 "", length=8)
                                             at ../../src/gdb/valops.c:1135
#8  0x000000000057335a in value_fetch_lazy (val=0x8f52b20)
                          at ../../src/gdb/valops.c:1018
#9  0x0000000000564975 in value_contents_for_printing (value=0x8f52b20)
                          at ../../src/gdb/value.c:842
#10 0x000000000057e747 in common_val_print (val=0x8f52b20,
                                            stream=0x10792f0, recurse=2,
                                            options=0x7fffffffcaa0,
                                            language=0x950500) at
                                            ../../src/gdb/valprint.c:454
#11 0x00000000005bb765 in print_frame_args (func=0x6ec32e0, frame=0x621f6b0,
                                            num=-1, stream=0xfac4e0)
                                            at ../../src/gdb/stack.c:381
#12 0x00000000005bb914 in print_args_stub (args=0x7fffffffcd00)
                          at ../../src/gdb/stack.c:434
#13 0x00000000005c30ff in catch_errors (func=0x5bb863
<print_args_stub>, func_args=0x7fffffffcd00, errstring=0x921f08 "",
mask=2) at ../../src/gdb/exceptions.c:506
#14 0x00000000005bc56f in print_frame (frame=0x621f6b0, print_level=1,
print_what=LOCATION, print_args=1, sal=...) at
../../src/gdb/stack.c:828
#15 0x00000000005bbdd4 in print_frame_info (frame=0x621f6b0,
print_level=1, print_what=LOCATION, print_args=1) at
../../src/gdb/stack.c:599
#16 0x00000000005bd9bc in backtrace_command_1 (count_exp=0x0,
show_locals=0, from_tty=0) at ../../src/gdb/stack.c:1382
#17 0x00000000005bdab8 in backtrace_command_stub (data=0x7fffffffcfc0)
at ../../src/gdb/stack.c:1421
...

> After all I found it is in many cases the fastest to upload the whole core
> file as then there are no RTT delays at all but that is offtopic here.

This is live server debugging.  Also, taking full core is often impractical,
as the RSS exceeds 20GB.


-- 
Paul Pluzhnikov