From: Paul Pluzhnikov <ppluzhnikov@google.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC][patch] Make DCACHE_LINE runtime-settable
Date: Mon, 25 Jul 2011 20:58:00 -0000 [thread overview]
Message-ID: <CALoOobNJwUW27ByDjC1JD3B90b8B270=C-U70WHtNSDKUKfXPQ@mail.gmail.com> (raw)
In-Reply-To: <20110725190008.GA30896@host1.jankratochvil.net>
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
next prev parent reply other threads:[~2011-07-25 20:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-23 2:40 Paul Pluzhnikov
2011-07-23 16:57 ` Eli Zaretskii
2011-07-25 15:01 ` Tom Tromey
2011-07-25 18:47 ` Paul Pluzhnikov
2011-07-25 19:22 ` Tom Tromey
2011-07-25 19:32 ` Pedro Alves
2011-07-25 19:33 ` Tom Tromey
2011-07-25 20:49 ` Pedro Alves
2011-07-25 20:22 ` Eli Zaretskii
2011-07-25 21:04 ` Paul Pluzhnikov
2011-07-26 0:28 ` Pedro Alves
2011-07-26 9:51 ` Eli Zaretskii
2011-07-25 19:26 ` Jan Kratochvil
2011-07-25 20:58 ` Paul Pluzhnikov [this message]
2011-07-26 2:55 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALoOobNJwUW27ByDjC1JD3B90b8B270=C-U70WHtNSDKUKfXPQ@mail.gmail.com' \
--to=ppluzhnikov@google.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox