Jim Blandy wrote:
> Russell Shaw <rjshawnetspace.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
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