This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH RFA] solib.c, symfile.c, symtab.h, and target.h changes
- To: Kevin Buettner <kevinb at cygnus dot com>
- Subject: Re: [PATCH RFA] solib.c, symfile.c, symtab.h, and target.h changes
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Tue, 21 Mar 2000 19:30:01 +1100
- CC: gdb-patches at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <1000318022821.ZM8341@ocotillo.lan>
Kevin Buettner wrote:
(yes, I'm the target vector maintainer. Thanks for the ping :-)
> The difficult part was choosing names for the new functions and
> deciding which header file should be used to declare the new
> functions. I ended up putting them next to the declaration of
> build_section_table() in target.h. target.h was the best choice
> for the following reasons:
The names are fine (make that pretty good).
> 1) The prototype for build_section_addr_info_from_section_table()
> refers to struct section_table *. This type is declared in
I consider it legitimate to use:
extern struct section_addr_info
*build_section_addr_info_from_section_table (const? struct section_table
*start, const const? section_table *end);
(An asside, this is why I also suggest people avoid ``typedef struct''
> 2) The return type for build_section_addr_info_from_section_table()
> is struct section_addr_info *. This type is declared in symtab.h.
> But target.h includes symtab.h. So this type is available to
> target.h as well.
I'll add that to my list of things to fix :-)
> 3) target.h already has a declaration for a function dealing with
> struct section_table *.
FYI, (and totally off the topic ...)
gdbarch is going to be broken into gdbarch.[hc] and gdbarch-utils.[hc].
target.[hc] is going to suffer a similar fate. Anything in target.[hc]
not directly relevant to the target vector is going to end up being
given the boot (to another file). Why? Any plan
multi-arching/multi-targeting GDB becomes just that bit more feasible if
the target vector is purged of all its current junk.
Anyway I'd rather target.[hc] didn't accumulate any more fluff.
(sorry, delete rant)
> Jim B. "pre-approved" me for checking in the changes to solib.c,
> symtab.h, and symfile.c. It's not clear to me who the maintainer
> for target.h is, so I'm seeking approval for those changes. (My
> guess is that Andrew is the maintainer by default.)
I'd suggest having the definitions in the header file that best
corresponds to the .c file that contains the functions implementation.
My guess is that symtab.h/symtab.c might be the best candidates since
symtab.h defines the struct that the function is building/freeing.
However one of the other files would proably be equally suitable.