Date: Wed, 17 Feb 1999 18:29:53 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: grog@lemis.com (Greg Lehey) Cc: tlambert@primenet.com, eivind@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: gdb sucks - and I need to get around it. help? Message-ID: <199902171829.LAA19473@usr07.primenet.com> In-Reply-To: <19990217133032.A515@lemis.com> from "Greg Lehey" at Feb 17, 99 01:30:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> Anybody know of any way of getting gdb to step from the start of the
> >> program?
> >>
> >> I have an executable with absolutely no symbol data (symbol data is
> >> absolutely non-available) which I *have* to get to step through, if
> >> necessary by re-implementing gdb.
> >
> > One really snotty way to do it is to write a small program that
> > exec's the other program, and follow it through the exec. I've used
> > this technique to work on ld.so before.
>
> Does this work on ELF executables?
I haven't tried it since my machine at work was switched, some time
after 3.0 became a little more stable and started putting the a.out
libraries and ld.so in the correct place (weeks after -RELEASE).
I rarely use source debuggers, preferring printf's and a deep
understanding of whatever code I'm hacking on. It's a prejudice I
carry from my VMS days, when the source level debugger linked into
the image, expanded the image space, and made the program stop
failing, more often than not; I haven't really trusted the damn
things since.
I actually *prefer* post-morteming core files, and instrumenting
the code such that I know what's going wrong.
I occasionally use the Microsoft source level debugger (I have to
admit that getting the contents of variables as a tool-tip, merely
by leaving the mouse pointer over them for a second is pretty damn
cool), but like the VMS debugger (and, frequently, gdb), you have
to remember what was happening right before everything went to hell,
and then step through it and stop just before it happens again.
Frankly, source level debuggers just take too frigging long to do
the job. I can edit in 10 DPRINTF(("HERE #1\n"));'s recompile, run,
see "HERE #6", edit in another 10 DPRINTF(("HERE #6.1\n"));'s, and
be done before I could step through once, let alone twice.
Maybe if someone invents a debugger that can replay the last 10
steps, and the last 10 control breaks, e.g., the last 10 for
loop iterations, and the entry conditions into the for loop, the
while loop before it, the function call they're in, etc.. It'd
be a lot of state to hold onto, but it would make the thing at
least minimally usable. Assuming it's not Windows, of course; if
you BSOD, you'll have a hell of a time replaying anything. 8-(.
Are you listening, xgdb or ups?
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902171829.LAA19473>