This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: gdb/2237: "set" command refuses to set a register
- From: Stephen Ma <stephenma at telus dot net>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 8 Mar 2007 18:38:02 -0000
- Subject: Re: gdb/2237: "set" command refuses to set a register
- Reply-to: Stephen Ma <stephenma at telus dot net>
The following reply was made to PR gdb/2237; it has been noted by GNATS.
From: Stephen Ma <stephenma@telus.net>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2237: "set" command refuses to set a register
Date: Thu, 8 Mar 2007 10:31:43 -0800
(I forgot to CC gdb-gnats in my previous message; the CC is back.)
On Wed, Mar 07, 2007 at 09:48:39PM -0500, Daniel Jacobowitz wrote:
> On Wed, Mar 07, 2007 at 05:04:49PM -0800, Stephen Ma wrote:
> > Not in a program written purely in assembler, in my long experience.
>
> Frequently, in programs written purely in assembler, in mine. I
> suspect it depends on the domain and the programmer.
Perhaps it does, but your self-discipline would be atypical. My
experience with assembler programming spans several decades and many
large teams. Believe me, ad hoc calling sequences are the
overwhelming norm, not the exception, in programs written purely in
assembler.
> > Sometimes gdb is too smart for its own good. If the problem isn't
> > unique to assembler, how about this:
> >
> > set dumb_gdb on
> >
> > This would disable the fancy stack walking. Let me decipher the stack
> > by myself and give me gdb, the dumb-but-reliable debugger! :)
>
> Or just fix the bug. GDB's stack walking infrastructure is central to
> its design.
I doubt it's fixable in the sense of intelligently handling an
undecipherable stack. (Undecipherable, that is, to anything less than
a weak AI.) In this general case, gdb is likely to end up doing the
equivalent of dumb_gdb anyway.