From owner-freebsd-hackers Wed Feb 17 10:30:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 01CB5112EA; Wed, 17 Feb 1999 10:30:04 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id LAA07135; Wed, 17 Feb 1999 11:29:58 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpd007112; Wed Feb 17 11:29:55 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id LAA19473; Wed, 17 Feb 1999 11:29:53 -0700 (MST) From: Terry Lambert Message-Id: <199902171829.LAA19473@usr07.primenet.com> Subject: Re: gdb sucks - and I need to get around it. help? To: grog@lemis.com (Greg Lehey) Date: Wed, 17 Feb 1999 18:29:53 +0000 (GMT) Cc: tlambert@primenet.com, eivind@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <19990217133032.A515@lemis.com> from "Greg Lehey" at Feb 17, 99 01:30:32 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> 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