This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 3/5] set/show code-cache


[sorry for the resend, I didn't catch that gmail had switched to rich text mode]

On Sat, Oct 26, 2013 at 6:22 AM, Yao Qi <yao@codesourcery.com> wrote:
> On 10/25/2013 11:57 PM, Doug Evans wrote:
>>>
>>> At the very beginning, I use single dcache for both stack access and code
>>> >access.  However, it is odd that command "set stack-cache off"
>>> > invalidates
>>> >code caches, so I decide to add a new cache dedicated to code access.
>>
>> If it's just that "set stack-cache off" flushed the cache (as opposed
>> to disabling/breaking all future use) I think that's ok.  How often
>> will it get turned on and off?
>>
>
> It is confusing if command "set stack-cache off" flushes both stack cache
> and code cache.  I'd like to have separate stack cache and code cache, so
> that GDB can control them independently.  GDB invalidates stack cache when
> GDB resumes inferior, but GDB doesn't have to invalidate code cache, unless
> the program is self-modified.

I guess the confusing part is having named the option "set stack-cache
on,off".  Sorry about that.

The dcache as it is today is a global cache, used by everything.  It's
not intended to be called "the stack cache". As you know, it's also
used when a range of memory is marked cacheable by the memory
attributes.

Note that GDB can't tell if the program has self-modifying code, and
GDB still has to handle the case of munmap (perhaps followed by an
mmap that happens to put different code at the same location).

Besides, won't better trust-readonly support handle the majority of
desired cases anyway?


> If we obsolete command "set stack-cache" and replace it with command "set
> target-cache", I agree that we can use single cache for stack and code.
> WDYT?

"set stack-cache on|off" is an escape hatch in case the optimization
we do to speed up backtraces on remote targets doesn't work in some
situation - the user has a knob to turn it off.  Maybe we could rename
it to "set stack-cache-optimization on|off" or some such.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]