This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: PATCH: Support x86 pseudo registers
> From: Pedro Alves <pedro@codesourcery.com>
> 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.