From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18346 invoked by alias); 12 Mar 2010 16:04:48 -0000 Received: (qmail 18202 invoked by uid 22791); 12 Mar 2010 16:04:47 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 12 Mar 2010 16:04:43 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0KZ600J00F6EOO00@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Fri, 12 Mar 2010 18:04:40 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.70.214.230]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KZ600JGGFBR8R20@a-mtaout20.012.net.il>; Fri, 12 Mar 2010 18:04:40 +0200 (IST) Date: Fri, 12 Mar 2010 16:04:00 -0000 From: Eli Zaretskii Subject: Re: PATCH: Support x86 pseudo registers In-reply-to: <201003121526.37646.pedro@codesourcery.com> To: Pedro Alves Cc: gdb-patches@sourceware.org, hjl.tools@gmail.com, msnyder@vmware.com Reply-to: Eli Zaretskii Message-id: <83iq9134rm.fsf@gnu.org> References: <20100301170152.GA20106@intel.com> <201003120423.07852.pedro@codesourcery.com> <83ljdy0wn9.fsf@gnu.org> <201003121526.37646.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-03/txt/msg00458.txt.bz2 > From: Pedro Alves > Date: Fri, 12 Mar 2010 15:26:37 +0000 > Cc: hjl.tools@gmail.com, > msnyder@vmware.com > > > > I just realized that this change means that $sp is now just > > > a 16-bit word of $esp, instead of a pseudo-register resolving to > > > either $esp/$rsp (32-bit/64-bit). I can't say it is actually wrong to > > > have it that way > > > > I think it's very wrong, because it means we no longer have a generic > > stack pointer register, at least not on x86. Is that true? > > A certainly agree very much that it's not convenient to have > $sp not be the largest stack pointer. I said the above based on: > > @cindex standard registers > @value{GDBN} has four ``standard'' register names that are available (in > expressions) on most machines---whenever they do not conflict with an > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > architecture's canonical mnemonics for registers. The register names > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > @code{$pc} and @code{$sp} are used for the program counter register and > the stack pointer. @code{$fp} is used for a register that contains a > pointer to the current stack frame, and @code{$ps} is used for a > register that contains the processor status. For example, > you could print the program counter in hex with > > So, should that sentence of the manual be relaxed? Maybe, but frankly I don't really understand what it says, exactly. Does it mean that if the name does clash with the architecture, the architecture's meaning is used? Anyway, are there any such conflicts in the current codebase? > I guess this would be a good place to at least mention the x86 $sp > is always $esp or $rsp. Yes, I think so.