Re: Gdb

[Russell Shaw <rjshaw@netspace.net.au>]

Jim Blandy wrote:
> Russell Shaw <rjshaw@netspace.net.au> writes:
> 
>>After narrowing down a bug location in the last few days, it seems
>>all too obvious that gdb needs to be gutted and recast. It can all
>>be made simpler and more understandable, thus easier to maintain.
> 
> I think you should give it a shot.  I'd love to see a proper set of
> libraries for controlling processes and interpreting debugging
> information.  You may want to look at Frysk, which is a newer design
> taking a very different approach, but addressing many of the same
> kinds of problems that GDB tries to.
> 
> I've come to think that trying to do involved symbolic processing
> (types; scoping; overload resolution; and multiply by ten where C++ is
> involved) without garbage collection is like trying to build a pocket
> watch out of sawdust and superglue.  Frysk is written in Java.

I didn't know about Frysk. The problem is it's in Java, and java is too indirect
and resource consuming for me.

I made a scoped hierarchial automatic garbage collecting system for C where if
you created an object on the heap between these (possibly nested) macros:

   auto_scope

     AnObject *myobject = mem_new(anoldobject, AnObject);
     ...
     auto_ret(ret_result);
   end_auto
   ...
   return another_result


then any objects within the scope is automatically freed after endauto or auto_ret
if they aren't "owned" by another object outside the scope such as anoldobject.
It works for arbitraryly deep scope, and across long-jumps. A global tree of object
ownerships is maintained, so if a parent of an object is mem_freed() that has other
parents, then the object is not freed() until it has no more parents (an automatic
version of refcounts). You can also modify the scope level of objects, which is
something that is normally unmodifiable in other languages.

After getting it working, i found it slowed the code by 5-10 times and used quite a
bit of memory, because new memory-tracking objects were being used for every small
mem_malloc i did, which were very frequent (thousands per second). It's best to use
this sought of thing for tracking larger (eg, 64-byte) less frequently created objects.

I found later another hierarchial memory manager called Talloc used in Samba.
Haven't used it though. It didn't do as much as i wanted.

I'm still wondering if something like the more manual but faster cleanup chains of
gdb would be a good way of doing things.

> But I would also say that what you've written here looks to me like a
> pretty common reaction of people who've had good experiences writing
> their own code to unfamiliar and complex programs; and at least in my
> own experience, it often mellows as one works with the code more.

Hi,
I've got a closer idea of what/where the problem is now, after looking
through 2k lines of back-traces at various stages during "run" from
delete_breakpoint().

A thing i didn't like is that eg, solib_read_symbols() will eventually mess
around with resetting breakpoints 6 frames deeper in the stack. I would have
handled breakpoint readjustments *after* solib_read_symbols(). I don't know
if it is practical without knowing how all paths operate in greater detail
on all systems and targets. Because i know how it works for the current case,
it seems easier to make a minor patch than to rearrange anything.


#0  delete_breakpoint (bpt=0x84ddd58) at breakpoint.c:6750
#1  0x080e57a0 in breakpoint_re_set_one (bint=0x84ddd58) at breakpoint.c:7206
#2  0x0812ad08 in catch_errors (func=0x80e5264 <breakpoint_re_set_one>, func_args=0x84ddd58, 
errstring=0x898d310 "Error in re-setting breakpoint -413:\n", mask=6) at exceptions.c:515

#3  0x080e5825 in breakpoint_re_set () at breakpoint.c:7248
#4  0x0810e6bf in new_symfile_objfile (objfile=0x8bb8ca0, mainline=0, verbo=0) at symfile.c:868
#5  0x0810e9fb in symbol_file_add_with_addrs_or_offsets (abfd=0x8b66108, from_tty=0, 
addrs=0x8b8cf48, offsets=0x0, num_offsets=0, mainline=0, flags=8) at symfile.c:1019

#6  0x0810ea5f in symbol_file_add_from_bfd (abfd=0x8b66108, from_tty=0, addrs=0x8b8cf48, mainline=0, 
flags=8) at symfile.c:1039

#7  0x0810ea98 in symbol_file_add (name=0x8b88c58 "/usr/lib/libXfixes.so.3", from_tty=0, 
addrs=0x8b8cf48, mainline=0, flags=8) at symfile.c:1052

#8  0x08091869 in symbol_add_stub (arg=0x8b88a50) at solib.c:406
#9  0x0812ad08 in catch_errors (func=0x80917a0 <symbol_add_stub>, func_args=0x8b88a50, 
errstring=0x826c0b0 "Error while reading shared library symbols:\n", mask=6) at exceptions.c:515

#10 0x08091916 in solib_read_symbols (so=0x8b88a50, from_tty=0) at solib.c:432
#11 0x08091c95 in solib_add (pattern=0x0, from_tty=0, target=0x8317100, readsyms=1) at solib.c:684
#12 0x0811fc1b in handle_inferior_event (ecs=0xbf8931f4) at infrun.c:2198
#13 0x0811dc52 in wait_for_inferior () at infrun.c:1009
#14 0x0811da7e in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_0, step=0) at infrun.c:827
#15 0x0811a704 in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0) at infcmd.c:556