From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: memory regions, dcache Date: Mon, 12 Jun 2000 18:44:00 -0000 Message-id: <394591DA.EADE0A0F@cygnus.com> References: <5mk8fyvfzy.fsf@jtc.redback.com> <3944A778.74396B73@cygnus.com> <5mbt164io6.fsf@jtc.redback.com> X-SW-Source: 2000-06/msg00107.html "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 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 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 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 To: Daniel Berlin Cc: Stan Shebs , Andrew Cagney , GDB Discussion 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> 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 To: Eric Bachalo 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> 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 To: Jim Ingham Cc: GDB Discussion 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: 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 To: Daniel Berlin 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> 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 To: Daniel Berlin Cc: Stan Shebs , GDB Discussion Subject: Re: That vision thing ... Date: Mon, 12 Jun 2000 19:21:00 -0000 Message-id: <39459A33.678EE727@cygnus.com> References: 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 To: Anatoly Vorobey 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: 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 >