* A consistent get/unwind frame naming schema
@ 2003-06-12 13:29 Andrew Cagney
2003-06-17 19:48 ` Andrew Cagney
0 siblings, 1 reply; 2+ messages in thread
From: Andrew Cagney @ 2003-06-12 13:29 UTC (permalink / raw)
To: gdb
It's been noted (and I know my self) that the frame's current naming
schema isn't exactly consistent. It came about because there was a
consistent naming schema but I didn't notice it until after adding
several new functions. Anyway, it would probably be a good idea to
clean it up before 6 - the change is mindless, just tedious.
So, I'd like to suggest the following.
Prefixes:
get_frame_WHAT*:
get WHAT from the THIS frame
(functionaly equivalent to THIS->next->unwind->what)
frame_unwind_WHAT*:
unwind THIS frame's WHAT from the NEXT frame
safe_*
safer version of various functions, doesn't throw an error
(leave this for later?) (*frame*_p instead?)
put_frame_WHAT*
put a value into this frame
(unsafe, need to invalidate the frame / regcache afterwards)
(better name more strongly hinting at its unsafeness)
Suffixes:
void *frame*_WHAT:
read WHAT's value into the buffer parameter
ULONGEST *frame*_WHAT_unsigned:
return an unsigned value
(the alternative is *frame_unsigned_WHAT)
LONGEST *frame*_WHAT_signed
return WHAT signed value
What:
*frame*_memory* (frame, coreaddr, len [, buf])
extract/return memory
*frame*_register* (frame, regnum [, buf])
extract/return register
*frame*_{pc,sp,...} (frame)
resume address, innner most stack address, ...
At least it is consistent.
Andrew
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: A consistent get/unwind frame naming schema
2003-06-12 13:29 A consistent get/unwind frame naming schema Andrew Cagney
@ 2003-06-17 19:48 ` Andrew Cagney
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Cagney @ 2003-06-17 19:48 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
Re-post. It just might be prudent to have this rename in before 6
branches. It will make importing mainline changes onto the branch easier.
Andrew
[-- Attachment #2: mailbox-message://ac131313@movemail/fsf/gdb/misc#4832368 --]
[-- Type: message/rfc822, Size: 3893 bytes --]
From: Andrew Cagney <ac131313@redhat.com>
To: gdb@sources.redhat.com
Subject: A consistent get/unwind frame naming schema
Date: Thu, 12 Jun 2003 09:29:41 -0400
Message-ID: <3EE88045.5060900@redhat.com>
It's been noted (and I know my self) that the frame's current naming
schema isn't exactly consistent. It came about because there was a
consistent naming schema but I didn't notice it until after adding
several new functions. Anyway, it would probably be a good idea to
clean it up before 6 - the change is mindless, just tedious.
So, I'd like to suggest the following.
Prefixes:
get_frame_WHAT*:
get WHAT from the THIS frame
(functionaly equivalent to THIS->next->unwind->what)
frame_unwind_WHAT*:
unwind THIS frame's WHAT from the NEXT frame
safe_*
safer version of various functions, doesn't throw an error
(leave this for later?) (*frame*_p instead?)
put_frame_WHAT*
put a value into this frame
(unsafe, need to invalidate the frame / regcache afterwards)
(better name more strongly hinting at its unsafeness)
Suffixes:
void *frame*_WHAT:
read WHAT's value into the buffer parameter
ULONGEST *frame*_WHAT_unsigned:
return an unsigned value
(the alternative is *frame_unsigned_WHAT)
LONGEST *frame*_WHAT_signed
return WHAT signed value
What:
*frame*_memory* (frame, coreaddr, len [, buf])
extract/return memory
*frame*_register* (frame, regnum [, buf])
extract/return register
*frame*_{pc,sp,...} (frame)
resume address, innner most stack address, ...
At least it is consistent.
Andrew
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-06-17 19:48 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-12 13:29 A consistent get/unwind frame naming schema Andrew Cagney
2003-06-17 19:48 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).