This is the mail archive of the 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]

Re: memory regions, dcache

"J.T. Conklin" wrote:
> >>>>> "Andrew" == Andrew Cagney <> writes:
> >> Now that the mem_attrib argument is available, target *_xfer_memory()
> >> functions may be able to tailor their behavior accordingly.  I say
> >> 'may be able' because currently most of the functions simply ignore
> >> the new arguement (either because the function has not been changed to
> >> use the attribute, or perhaps because the host/target interface/
> >> protocol cannot support the attribute(s) selected.  Is there anything
> >> I should do about this now, or is the fact that some attributes are
> >> not supported on all targets a given that just needs to be documented?
> Andrew> If a user sets (pick a random attribute) the atomic attribute
> Andrew> (see next paragraph) but the target doesn't support it
> Andrew> shouldn't the user be told that the attribute was ignored?  I
> Andrew> think it is important to not mis-lead the user with this.
> I agree.  However, I'm having a hard time thinking of a implementation
> that is easy to maintain.  While it wouldn't be difficult to add code
> that checks attrib->width and prints a message for unsupported access
> types, this would have to be done each time a new low-level attribute
> was defined.  This will do if necessary, but I'd prefer something more
> robust.  With so many targets, it seems likely that some are going to
> be missed.

If there were such a mechanism, how would it work?

Would it be, for instance:

	o	when the attribute is set,
		the dcache check that the target
		at lest know about the attribute
		and can handle it in principal.

		remote.c might run a probe to see
		if it is valid.  Like the X packet
		is currently probed.

		The default would be to assume it
		wasn't supported.

		Extending individual targets so that
		they support all attributes should
		not be your problem.  That is the
		responsibility of the individual
		target maintainers.

	o	when a transfer occures,
		would the target potentially
		turn around and reject the transaction
		because, while the attribute is supported,
		it isn't applicable to that address range.

		Even with the first check this second
		situtation will still occure.

If that were the model, then a separate attribute-supported-p method
would need to be added.

I think as a basic approach, this is reasonable.  Make a preliminary
sanity check but watch out for things still failing.

> >> For example, instead of calling a target vector's *to_xfer_memory(),
> >> target_xfer_memory() would call dcache_xfer_memory() with a target
> >> vector pointer.  If dcache_xfer_memory() had to do i/o, it would call
> >> the target vector's *to_xfer_memory() function.
> Andrew> I think the elegant solution is preferable (but as you ask, is
> Andrew> it feasible?).
> I think it is too.  But to avoid biting off too much at once, I've
> decided to get there incrementally.  The low level memory read/write
> functions need to be changed to handle attributes anyway, and I need
> to some time to think about the ramifications of moving up dcache.
> For example, there are now separate caches for each target vector, in
> the new scheme there would only be one.

Ha! Thats nothing.  Long long term there will be a dcache per
virtual/physical address space.  Again, however, that isn't your problem

Hmm, the target strata stike again :-(.  Avoiding that is probably

> Andrew> However, is there any evidence that people actually use it?
> The cache in general, or the 'set remotecache' command?

Both.  Do WINCE people disable the cache.  Do non WINCE people enable
the cache.


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