memory regions, dcache

memory regions, dcache

[J.T. Conklin]

Setting aside symbol table performance for the moment, I'm back
finishing up memory region attributes.

In previous messages, I've shared my changes to target_xfer_memory().
Those have not changed significantly.  Since that time, I've added a
'mem_attrib *attrib' argument to the target vectors to_xfer_memory()
function, and have fixed up all the code for all the targets.  While I
was there, I noticed that some target's *_xfer_memory() function did
not declare the 'struct target_ops *target' argument, so I fixed that
up at the same time.  (Btw, Are there any *_xfer_memory() functions
that use the 'target' argument?  I didn't see any while I was adding
the new argument, but I wasn't looking for it either.  If nothing uses
it, I wouldn't mind removing it as part of this change.)

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?

In most of the embedded remote targets, the target vector code calls
dcache_init() in the *_open() function to register functions used to
read and write memory, and the *_xfer_memory() functions calls
dcache_xfer_memory() which uses the functions registered earlier to
perform the I/O.  The problem is that there is no way to pass the
attribute argument through dcache to the functions.  

This should be fairly easy to address --- just a lot of grunt work
fixing up dcache_xfer_memory() and the read and write functions to
take the new argument.  However, I wonder whether it would be better
(cleaner, more "elegant", etc.) to move dcache up a layer and put it
between target_xfer_memory() and the target *_xfer_memory() functions.

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.

Having the dcache at a higher level might be useful for implementing
the verify (read and compare after writes) attribute.  As I imagine
things, verify support would be implemented in target_xfer_memory()
and would re-read and compare after a write.  But if the target code
uses dcache, the read would not come from the target but the cache.
On the other hand, target_xfer_memory() could do a cache invalidate
before reading (and a more refined cache invalidate could easily be
written).

All that being said, I think that going the simple route and adding
the parameter to dcache_xfer_memory() and to the target read/write
functions may be the right thing for now.  It won't be difficult to
re-evaluate this decision and go for the more integrated approch if
that turns out to be the right thing over time.

One more thing before this gets too long.  There is a remotecache
variable that globally enables the cache which is currently disabled.
With attributes, each memory region has a cache/nocache atttribute.
Should the remotecache variable override the attribute.  Or can we
depricate remotecache completely?  Since when no memory attributes
are defined the default attribute is used which disables the cache,
there isn't much need for a global flag any more.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From kevinb@cygnus.com Fri Jun 09 12:22:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Comments on U_REGS_OFFSET and fetch_register...
Date: Fri, 09 Jun 2000 12:22:00 -0000
Message-id: <1000609192235.ZM24244@ocotillo.lan>
X-SW-Source: 2000-06/msg00067.html
Content-length: 1586

In infptrace.c, U_REGS_OFFSET is (conditionally) defined as follows:

/* U_REGS_OFFSET is the offset of the registers within the u area.  */
#if !defined (U_REGS_OFFSET)
#define U_REGS_OFFSET \
  ptrace (PT_READ_U, inferior_pid, \
	  (PTRACE_ARG3_TYPE) (offsetof (struct user, u_ar0)), 0) \
    - KERNEL_U_ADDR
#endif

And later on, in fetch_register(), we have the following code:

  /* Overload thread id onto process id */
  if ((tid = TIDGET (inferior_pid)) == 0)
    tid = inferior_pid;		/* no thread id, just use process id */

  offset = U_REGS_OFFSET;

  ...

      *(PTRACE_XFER_TYPE *) & buf[i] = ptrace (PT_READ_U, tid,
					       (PTRACE_ARG3_TYPE) regaddr, 0);


I have two problems with this code.

 1) U_REGS_OFFSET is still using the composite thread id / process id.
    It should only be using the actual pid extracted from
    inferior_pid.  

    In my opinion, U_REGS_OFFSET should be changed (everywhere) to
    take the pid as an argument.

 2) The tid being extracted is later passed to ptrace().  While this
    is fine for linux, where the tid is actually a pid which makes
    sense to pass to ptrace(), I really doubt it makes sense for other
    threads implementations where the thread id is something else
    entirely.

    I'm not sure what to do about this problem.  Perhaps its a moot
    point since native ports where this could be a problem likely
    define FETCH_INFERIOR_REGISTERS in order to do the right thing
    when it comes to the thread id.  Still it looks more than a little
    strange to be passing the thread id to ptrace().

Kevin

Re: memory regions, dcache

[Andrew Cagney]

"J.T. Conklin" wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> 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
safer.

> 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.

	Andrew
From toddpw@windriver.com Mon Jun 12 18:47:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: gdb@sourceware.cygnus.com
Cc: insight@sourceware.cygnus.com ("Insight (GDB GUI)")
Subject: Re: non-blocking reads/writes and event loops
Date: Mon, 12 Jun 2000 18:47:00 -0000
Message-id: <200006130147.SAA22432@alabama.wrs.com>
References: <3944B786.A16E9A2F@cygnus.com>
X-SW-Source: 2000-06/msg00108.html
Content-length: 715

> The thing that needs to be decided is how far GDB should be pushed to
> address this problem.  Should GDB continue to be pushed to the point
> where everything is event based or should, the current compromise remain
> where a GUI is unable to exploit GDBs event-loop.

I am a advocate of long-time eventification. We should not create a mess
in an attempt to do it quickly, but it should remain a long-term goal.
The flexibility that we gain in doing so will pay us back later.

In particular, I think it is extremely inappropriate for GDB itself to
require threads. That would, in principle, be about as bad as allowing
parts of GCC to require a working C++ compiler...

-- 
Todd Whitesel
toddpw @ windriver.com
From toddpw@windriver.com Mon Jun 12 18:51:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: shebs@apple.com
Cc: ac131313@cygnus.com (Andrew Cagney), gdb@sourceware.cygnus.com (GDB Discussion)
Subject: Re: That vision thing ...
Date: Mon, 12 Jun 2000 18:51:00 -0000
Message-id: <200006130150.SAA22461@alabama.wrs.com>
References: <39458D05.9B3411C1@apple.com>
X-SW-Source: 2000-06/msg00109.html
Content-length: 202

> I agree that these are the two biggies.  We could call the second
> "multi-everything" :-)

Careful, Green Hills has a trademark on "MULTI" -- 1 guess why...

-- 
Todd Whitesel
toddpw @ windriver.com
From cgf@cygnus.com Mon Jun 12 18:51:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: Stan Shebs <shebs@apple.com>, Andrew Cagney <ac131313@cygnus.com>, GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: That vision thing ...
Date: Mon, 12 Jun 2000 18:51:00 -0000
Message-id: <20000612215121.A8887@cygnus.com>
References: <39458D05.9B3411C1@apple.com> <Pine.LNX.4.10.10006121826130.29924-100000@propylaea.anduin.com>
X-SW-Source: 2000-06/msg00110.html
Content-length: 678

On Mon, Jun 12, 2000 at 06:31:57PM -0700, Daniel Berlin wrote:
>I consider the type changes i'm making rather big as well.
>Also, on my list, as part of the type changes, is making the vtable using
>code, and overload resolution, generic.
>After that, redoing the symbol table structure.
>And for an encore, i'll rewrite gdb in C++.
>Estimated Time To Completion: 2 days, give or take 2 hours.
>:)

I think I have to revise my usual method of doubling and increasing by
then next time unit when I see (or propose) an engineering time estimate.

That would mean that you'd have this done in four months give or take
four days.

Surely, this would take at least five months.

cgf
From kevinb@cygnus.com Mon Jun 12 18:55:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Eric Bachalo <ebachalo@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Proposal: convert function definitions to prototyped form
Date: Mon, 12 Jun 2000 18:55:00 -0000
Message-id: <1000613015531.ZM16436@ocotillo.lan>
References: <1000602075018.ZM29997@ocotillo.lan> <200006021226.e52CQ2I01239@delius.kettenis.local> <1000602151553.ZM30578@ocotillo.lan> <5mya4om115.fsf@jtc.redback.com> <394572A4.EF8646F2@redhat.com> <ebachalo@redhat.com>
X-SW-Source: 2000-06/msg00111.html
Content-length: 3446

On Jun 12,  4:30pm, Eric Bachalo wrote:

> > You can tell indent about all the types defined by typedef with -T
> > option, and then it won't add the extra space.  It shouldn't be too
> > difficult to identify all the types.
> > 
> > It might be useful for us to maintain an indent.pro file that has
> > these definitions so that additional runs of indent don't add back
> > the space.
> 
> I believe etags does a fairly good job a finding typedefs.  I would be a
> fairly simple script to parse the TAGS file to make a list of all typedefs.  I
> have a python script for this.  Not sure how ported etags and python are for
> all the hosts that compile GDB though. 

What you suggest would work so long as you also run etags over the
system header files.

For the task at hand, however, the check-decls script has already
identified the necessary types.  (Recall that check-decls is run on
the "diff -u" output after doing a fix-decls.  It constructs a program
which is then compiled with "gcc -Wall" to check the validity of the
protoization performed by fix-decls.  In the process of constructing
the validating program, it must first identify all of the types
requiring typedefs.)

Here is the list of types found by check-decls:

    ADDR32, B_TYPE, COMMON_ENTRY_PTR, CORE_ADDR, CPUSpace, DCACHE,
    DIE_REF, DOUBLEST, EXTR, EventRecord, FDR, FILE, HWND, INSN_WORD,
    INT32, LONG, LONGEST, LPARAM, LRESULT, PDR, PTR, PTRACE_ARG3_TYPE,
    PXDB_header_ptr, Point, Ptrace_return, RDB_EVENT, REGISTER_TYPE,
    RgnHandle, Rptrace, SAVED_BF_PTR, SAVED_F77_COMMON_PTR,
    SAVED_FUNCTION, SYMR, TTRACE_ARG_TYPE, UINT, ULONGEST, WAITTYPE,
    WPARAM, WindowPtr, XDR, YYSTYPE, alpha_extra_func_info_t,
    arg_array, arg_one, arg_type, arg_value, argsin, asection,
    attach_continue_t, bfd, bfd_arch_info_type, bfd_byte,
    bfd_signed_vma, bfd_vma, bool_t, boolean, boolean_t, bpstat,
    branch_type, catch_errors_ftype, catch_fork_kind, cma__t_int_tcb,
    disassemble_info, dld_cache_t, dnttpointer, dst_rec_ptr_t,
    dst_sec, dst_sect_ref_t, dst_type_t, file_ptr, fltset_t,
    fpregset_t, func_call, gdb_client_data, gdb_fpregset_t,
    gdb_gregset_t, gdb_thread_t, gdb_threadref, gregset_t,
    host_callback, insertion_state_t, insn_type, kern_return_t,
    lwpid_t, mach_msg_header_t, mach_msg_id_t, mach_msg_type_name_t,
    mach_port_mscount_t, mach_port_t, memory_page_t, memxferfunc,
    mips_extra_func_info_t, namespace_enum, off_t, pid_t,
    port_chain_t, process_state_t, procinfo, quick_file_entry,
    quick_module_entry, quick_procedure_entry, return_mask,
    rmt_thread_action, sec_ptr, serial_t, serial_ttystate, sigset_t,
    size_t, sltpointer, stepping_mode_t, sysset_t, t_inst, task_t,
    td_err_e, td_thr_state_e, td_thr_type_e, td_thragent_t,
    td_thrhandle_t, thread_array_t, thread_info, thread_t, threadinfo,
    threadref, time_t, tree, ttevents_t, ttreq_t, ttstate_t, ttwopt_t,
    u_long, ui_file_delete_ftype, ui_file_flush_ftype,
    ui_file_fputs_ftype, ui_file_isatty_ftype, ui_file_put_ftype,
    ui_file_rewind_ftype, va_list, value_ptr, and xdrproc_t

Note that there are likely typedefs for types in the gdb sources
missing from the above list, but these were not necessary for doing
the fix-decls conversion.  Also, there are some in the above list
which are defined in system header files.  But that's okay because
indent still needs to know about them in order to do a good job of
formatting.
From ac131313@cygnus.com Mon Jun 12 19:02:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Ingham <jingham@apple.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: non-blocking reads/writes and event loops
Date: Mon, 12 Jun 2000 19:02:00 -0000
Message-id: <3945960A.C8ED9B76@cygnus.com>
References: <B56A728C.1003%jingham@apple.com>
X-SW-Source: 2000-06/msg00112.html
Content-length: 892

Jim Ingham wrote:

> So my vote is to eradicate ALL the blocking behavior, and make GDB a pure
> event driven application.  In the cases where you can't avoid blocking calls
> (like ptrace calls, for instance) we should consider spinning a helper
> thread, and doing the work there.  I am not in favor of a thread-happy
> approach for gdb, but the careful use of short-lived threads to do
> particular tasks is a lot more stable than forcing interrupt-driven
> programming on the unhappy GUI's that attempt to use gdb...

Thing is, it is hard.

It means completly inverting the expression evaluator.  I've seen an
outline for how to do it so that just inferior calls are async.  Making
GDB fine-grain event based means that even memory and register transfers
are restartable.

However, making GDB responsive to more than one active target may force
the issue, regardless of any GUI.

	Andrew
From mellon@pobox.com Mon Jun 12 19:16:00 2000
From: Anatoly Vorobey <mellon@pobox.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Proposal: convert function definitions to prototyped form
Date: Mon, 12 Jun 2000 19:16:00 -0000
Message-id: <20000613051645.A13495@happy.checkpoint.com>
References: <39458A9E.239C8A81@apple.com> <Pine.LNX.4.10.10006121815430.29924-100000@propylaea.anduin.com>
X-SW-Source: 2000-06/msg00113.html
Content-length: 1339

On Mon, Jun 12, 2000 at 06:23:27PM -0700, Daniel Berlin wrote:
> Before my patches to eliminate duplicate dwarf2 info, it said there were
> 120k. 
> So something isn't adding up here. 

How do you eliminate them? The vast majority of types in debug info
are duplicate header file types coming from different source files.
Reducing this should cut the number much more drastically than
from 120k to 80k. I'd say by factor of 8 at the very least. 

My code which reads stabs info says that there are 52276 types (not
trying to remove duplicates) defined
in gdb (not including libbfd, libiberty and libopcodes; including them
gives another 13000 or so) and of them 886 unique type *names*. This
gives a lower bound, obviously, since names may be reused or may denote
different types even coming from the same header due to different defines --
but it's also more useful than the raw number since it doesn't count the
multitude of unnamed automatically generated types which are pointers, 
aliases, forward references, etc.

That would mean around one type name per 400 lines of code. Since almost all
type declarations are in header files which are about 1/10 of all sources
in size, it looks reasonable. 

-- 
Anatoly Vorobey,
mellon@pobox.com http://pobox.com/~mellon/
"Angels can fly because they take themselves lightly" - G.K.Chesterton
From ac131313@cygnus.com Mon Jun 12 19:21:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: Stan Shebs <shebs@apple.com>, GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: That vision thing ...
Date: Mon, 12 Jun 2000 19:21:00 -0000
Message-id: <39459A33.678EE727@cygnus.com>
References: <Pine.LNX.4.10.10006121826130.29924-100000@propylaea.anduin.com>
X-SW-Source: 2000-06/msg00114.html
Content-length: 1628

Daniel Berlin wrote:
> 
> >
> > I agree that these are the two biggies.  We could call the second
> > "multi-everything" :-)
> >
> > > As with any bit of open source, there is of course, no timeframe ...
> >
> > Somewhere around I still have the late-1994/early-1995 document
> > proposing that GDB ought to support multiple architectures at
> > runtime.  For a long time I was doubtful that it would ever
> > happen, but lo and behold, you made it real!  So yes, the big
> > changes can come about if we set them as our goals.
> >
> > Stan
> >
> I consider the type changes i'm making rather big as well.
> Also, on my list, as part of the type changes, is making the vtable using
> code, and overload resolution, generic.
> After that, redoing the symbol table structure.
> And for an encore, i'll rewrite gdb in C++.
> Estimated Time To Completion: 2 days, give or take 2 hours.
> :)

Remember, we're only allowed to rewrite GDB in scheme (N.B. is the GDB
collary to Godwin's law :-).

With regard to the the type changes I hear are being proposed, yes they
are very significant.  The key difference is in the logistics in
completing the work.  Changing types and language structures is largely
platform independant Once you've built/tested it on cygwin it will most
likely work for all platforms.  

bulk-arch (since we can't call it multi- :-) either involves modifying
every single host/target or at least figuring out a way to do things so
that nothing is broken.  It is a much slower more tedious operation.

Like I said, changes like yours are the ones that will be noticed and
receive the praise :-)

	enjoy,
		Andrew
From dan@cgsoftware.com Mon Jun 12 19:42:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: Anatoly Vorobey <mellon@pobox.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Proposal: convert function definitions to prototyped form
Date: Mon, 12 Jun 2000 19:42:00 -0000
Message-id: <Pine.LNX.4.10.10006121917250.29924-100000@propylaea.anduin.com>
References: <20000613051645.A13495@happy.checkpoint.com>
X-SW-Source: 2000-06/msg00115.html
Content-length: 1758

On Tue, 13 Jun 2000, Anatoly Vorobey wrote:

> On Mon, Jun 12, 2000 at 06:23:27PM -0700, Daniel Berlin wrote:
> > Before my patches to eliminate duplicate dwarf2 info, it said there were
> > 120k. 
> > So something isn't adding up here. 
> 
> How do you eliminate them? The vast majority of types in debug info
> are duplicate header file types coming from different source files.
> Reducing this should cut the number much more drastically than
> from 120k to 80k. I'd say by factor of 8 at the very least. 

Easy.
I have a simple hash table, 4096 entries right now.
before we read a type die, we see if the name of the type is in the hash
table (C++ ODR lets me, nobody with a C program has complained they have
the same type in multiple translation units that isn't really the same
type. I suspect it would break other stuff anyway), if it is, we use the
type in the hash table.
Otherwise, we enter it into the hash table.
If it's in the hash table, but the name doesn't match, i have some code
(not in gdb 5.0, because it's
noisy and only for profiling, obviously) to tell me it's a collision.
No collisions found.

Theoretically, this should remove all duplicate type info being read in if
there aren't any collisions.

So something else is making them, most likely lookup_pointer_type or
thereabouts.

I guess part of the problem is that we can't free types.

But i still think we generate way too many types.

> 
> That would mean around one type name per 400 lines of code. Since almost all
> type declarations are in header files which are about 1/10 of all sources
> in size, it looks reasonable. 
> 
> -- 
> Anatoly Vorobey,
> mellon@pobox.com http://pobox.com/~mellon/
> "Angels can fly because they take themselves lightly" - G.K.Chesterton
>