This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb/2237: "set" command refuses to set a register


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]