From: Doug Evans <dje@google.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org, Jacob Potter <jdpotter@google.com>
Subject: Re: [RFA] Use data cache for stack accesses
Date: Fri, 21 Aug 2009 06:25:00 -0000 [thread overview]
Message-ID: <e394668d0908202300v2982d0c4y7e8f71d337f0b1d7@mail.gmail.com> (raw)
In-Reply-To: <200907082146.40513.pedro@codesourcery.com>
On Wed, Jul 8, 2009 at 1:46 PM, Pedro Alves<pedro@codesourcery.com> wrote:
> On Wednesday 08 July 2009 21:08:00, Jacob Potter write:
>> --- a/gdb/thread.c
>> +++ b/gdb/thread.c
>> @@ -848,6 +848,9 @@ switch_to_thread (ptid_t ptid)
>> if (ptid_equal (ptid, inferior_ptid))
>> return;
>>
>> + if (ptid_get_pid (ptid) != ptid_get_pid (inferior_ptid))
>> + dcache_invalidate (target_dcache);
>> +
>
> I'm not sure this would be 100% multi-address space safe.
>
> Do we not have places where we switch inferior_ptid temporarily
> before calling reading memory, with save_inferior_ptid, without
> going through the high level switch_to_thread ?
Yeah.
> What if we do this within dcache itself, similarly
> to get_thread_regcache? That would be probably in [dcache_xfer_partial].
It seems that given that we can temporarily change inferiors without
giving subsystems notice of the change, and given vfork, then we need
to have intelligence in dcache to handle this (and then it's not clear
if we should keep one dcache per inferior).
How about having memory_xfer_partial notify dcache of every
write/read, and then dcache could keep just one copy of the cache and
flush it appropriately?
next prev parent reply other threads:[~2009-08-21 6:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-08 20:49 Jacob Potter
2009-07-08 20:51 ` Pedro Alves
2009-07-08 20:58 ` Pedro Alves
2009-07-08 23:46 ` Daniel Jacobowitz
2009-07-09 3:06 ` Pedro Alves
2009-07-10 9:34 ` Pedro Alves
2009-07-10 8:45 ` Jacob Potter
2009-07-10 14:19 ` Pedro Alves
2009-07-13 19:25 ` Jacob Potter
2009-08-21 6:25 ` Doug Evans [this message]
2009-08-25 3:00 ` Doug Evans
2009-08-25 18:55 ` Pedro Alves
2009-08-26 16:36 ` Doug Evans
2009-08-26 22:45 ` Pedro Alves
2009-08-27 0:46 ` Doug Evans
2009-08-27 3:11 ` Doug Evans
2009-08-29 5:16 ` Doug Evans
2009-08-29 18:28 ` Doug Evans
2009-08-29 20:25 ` Pedro Alves
2009-09-02 20:43 ` Tom Tromey
2009-09-03 15:38 ` Doug Evans
2009-09-03 19:38 ` Tom Tromey
2009-09-03 19:45 ` Daniel Jacobowitz
2009-07-09 12:20 ` Eli Zaretskii
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=e394668d0908202300v2982d0c4y7e8f71d337f0b1d7@mail.gmail.com \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=jdpotter@google.com \
--cc=pedro@codesourcery.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