This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfc] block.{h,c}
- From: David Carlton <carlton at math dot stanford dot edu>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com, Elena Zannoni <ezannoni at redhat dot com>, Jim Blandy <jimb at redhat dot com>
- Date: 19 Feb 2003 09:05:02 -0800
- Subject: Re: [rfc] block.{h,c}
- References: <ro165rhqkjt.fsf@jackfruit.Stanford.EDU><3E537F1B.2010601@redhat.com>
On Wed, 19 Feb 2003 07:56:59 -0500, Andrew Cagney <ac131313 at redhat dot com> said:
> Can it eventually contain the few remaining scraps of block* code
> found in blockframe.c (hint, hint :-)?
I don't see why not. The functions in blockframe.c that start with
block_* or blockvector_* are:
struct blockvector *
blockvector_for_pc_sect (register CORE_ADDR pc, struct sec *section,
int *pindex, struct symtab *symtab)
struct blockvector *
blockvector_for_pc (register CORE_ADDR pc, int *pindex)
struct block *
block_for_pc_sect (register CORE_ADDR pc, struct sec *section)
struct block *
block_for_pc (register CORE_ADDR pc)
struct frame_info *
block_innermost_frame (const struct block *block)
All of those seem like reasonable candidates for block.{c,h}.
> I think it is consistent with GDB's current overall direction - more
> modular with *.[hc] relating to specific objects or sets of objects.
That's my feeling, too.
David Carlton
carlton at math dot stanford dot edu