From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21872 invoked by alias); 5 Nov 2004 14:53:03 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21827 invoked from network); 5 Nov 2004 14:53:01 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 5 Nov 2004 14:53:01 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iA5EqtME017075 for ; Fri, 5 Nov 2004 09:53:00 -0500 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iA5Eqtr10313; Fri, 5 Nov 2004 09:52:55 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 97F72129D8C; Fri, 5 Nov 2004 09:52:41 -0500 (EST) Message-ID: <418B93B4.6020909@gnu.org> Date: Fri, 05 Nov 2004 14:53:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: Changing "info frame" output? References: <41890706.3060207@gnu.org> <200411042159.iA4Lxfpg011833@elgar.sibelius.xs4all.nl> In-Reply-To: <200411042159.iA4Lxfpg011833@elgar.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00044.txt.bz2 Mark Kettenis wrote: > Date: Wed, 03 Nov 2004 11:27:50 -0500 > From: Andrew Cagney > > Hello, > > GDB's current info frame output looks like: > > Stack level 1, frame at 0x7ffff290: > pc = 0x1005e5f8 in fprintf_filtered > (/home/scratch/GDB/src/gdb/utils.c:2231); > saved pc 0x1005a6b8 > called by frame at 0x7ffff2b0, caller of frame at 0x7ffff210 > source language c. > Arglist at 0x7ffff210, args: stream=0x10465888, > format=0x1036fe4c "GNU gdb %s\n" > Locals at 0x7ffff210, Previous frame's sp is 0x7ffff290 > Saved registers: > pc at 0x7ffff294, lr at 0x7ffff294 > > I see several problems (some apparent, some not so): > > - PC and SP as registers really no longer apply. > Phrases such as ``pc = ...'' and ``saved pc'', and ``Previous frame's > SP'' should be worded in a more ISA netural way. > Really? Really! http://sources.redhat.com/gdb/current/onlinedocs/gdb_9.html#SEC65 GDB 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 $pc and $sp are used for the program counter register and the stack pointer. $fp is used for a register that contains a pointer to the current stack frame, and $ps is used for a register that contains the processor status. Core GDB has concepts such as: - current instruction - stack inner-most bound - frame ID (which contains the "frame address") - frame base et.al. while an ISA may have related registers: - program-counter - frame-pointer - stack-pointer A register such as $fp _might_ refer to core GDB's idea of a frame address (id.stack_addr) but can equally refer to the ISA's "fp" register (see arm where for years we screwed up and printed the wrong "$fp"). Similarly for "pc", on VLIW, harvard and delay-slot ISAs, GDB's current-instruction while constructed from, is not the same value as $pc. > While the history of sp, fp and ps is defenitely related > to commonly used aliases for certain PDP11 registers, I really see > them as abstract registers. The program counter or instruction > pointer is a fundamental feature of the von Neumann architecture. All > the ISA's that I know of, have the concept of a stack pointer, > although in many of them the register used as a stack pointer is only > a software convention. The concept of a frame pointer is absent in > many modern ISA's, although some of them speak of a "virtual" frame > pointer. Most ISA's have somes sort of processor status register. > > So I see the names pc, sp, fp and ps as abbreviations for the concepts > I mention above. As such I see no problem in using them in the "frame > info" output. So what you're proposing is that "info frame" should display the value to "pc" and "fp", yet when the user prints $pc and $fp they get something entirely different. We've never resolved the question of what to call the convenience variables that correspond to the above core GDB concepts. Sounds like its time. > - Often there isn't an "Arglist at ..." > Modern architectures often don't push any arguments on the stack so the > argument address isn't meaningful. > > All the world's a VAX... However, Arglist... and Locals... are > relevant for various kinds of debug info, so we should retain the > possibility to print them. I wrote: > Where applicable frame locals and args addresses are also printed. see the source. > and with that in mind have come up with the following as a draft: > > Stack level 1, frame at 0x7ffff240: > Code at 0x1005e5f8 in fprintf_filtered (stream=0x10467888, > format=0x10371b74 "GNU gdb %s\n") > at /home/scratch/PENDING/2004-10-29-full-location/src/gdb/utils.c:2231 > called by frame at 0x7ffff260, caller of frame at 0x7ffff1c0 > Source language c. > Frame base at 0x7ffff1c0. > Registers saved by this frame: > pc at 0x7ffff244, lr at 0x7ffff244 > > Notice how: > > -- source location (second line) uses a more "standard" format > The one printed when switching frames using up/down. The format > includes the argment list. I've also modified it to print "Code at" > instead of "pc =". It could also read "Instruction at". > -- /Saved registers:/Registered saved by this frame/ > And the list can include registers saved in another register (but the > example doesn't show this). > > I'm still wondering: > > -- Frame's ID? > Should this be printed - the frame address is the frame ID's address > already. > > I don't think so. The frame ID is an internal GDB concept that we > shouldn't expose to the user. But we should print enough information > with "info frame" for the user to distinguish between frames. When it comes to scripting, frame ID is a critical part of a users life. Is has to be exposed. The question is where and how. > -- "saved pc" dropped > Perhaphs it should print "Return address ..."? > > I like "Return address". It's a general concept that doesn't contain > the misleading "saved". > > Your proposal no longer prints the "Previous frame's sp". I think > this leaves out important information. While core gdb has the concept of the parameter stack's inner-most bound (stack used to pass parameters) (a.k.a., stack extent?), used by the inferior function call code, it doesn't have a more general concept of "sp". That's ABI / ISA specific (IA-64 has two stacks for instance). Perhaphs ISA/ABI should be afforded the oportunity to print ISA/ABI specific information, or even provide an abi/isa specific frame-info command. Andrew