Re: [RFA] Revised C++ ABI abstraction patches

Re: [RFA] Revised C++ ABI abstraction patches

[Michael Elizabeth Chastain]

Lightly proofread, no obvious errors found.

I would prefer constructor_prefix_p et al to be real functions rather
than macros.  When I single-step code in gdb, it's a lot easier to follow
real functions than macros.

If I get some bandwidth I'll test it against gcc 2.95.2 and gcc-3pre
on a Solaris machine.

Michael

Re: [RFA] Revised C++ ABI abstraction patches

[Jim Blandy]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:
> Lightly proofread, no obvious errors found.

Great.  That means all the bugs still there are non-obvious, and will
take a long time to find.  Just make my day, will you.  (Thanks.)

> I would prefer constructor_prefix_p et al to be real functions rather
> than macros.  When I single-step code in gdb, it's a lot easier to follow
> real functions than macros.

I agree completely.  But it is not the standard practice (see target.h
and elsewhere) and others don't seem to mind.  So I reined in my prima
donna urges and left them as macros.

And besides, function calls are so slow.  Remember, GDB's performance
matters a lot --- it's used to debug real-time operating systems!

:(

> If I get some bandwidth I'll test it against gcc 2.95.2 and gcc-3pre
> on a Solaris machine.

If I get a bandstand I'll play the boogie 'til the sun goes down.

Re: [RFA] Revised C++ ABI abstraction patches

[Michael Snyder]

Jim Blandy wrote:
> 
> Michael Elizabeth Chastain <chastain@cygnus.com> writes:
> > Lightly proofread, no obvious errors found.
> 
> Great.  That means all the bugs still there are non-obvious, and will
> take a long time to find.  Just make my day, will you.  (Thanks.)
> 
> > I would prefer constructor_prefix_p et al to be real functions rather
> > than macros.  When I single-step code in gdb, it's a lot easier to follow
> > real functions than macros.
> 
> I agree completely.  But it is not the standard practice (see target.h
> and elsewhere) and others don't seem to mind.  So I reined in my prima
> donna urges and left them as macros.

There is an ongoing effort to get away from that.
Go ahead, Jim -- let your prima donna run free!  ;-)

> 
> And besides, function calls are so slow.  Remember, GDB's performance
> matters a lot --- it's used to debug real-time operating systems!

I assume you're joking.

Re: [RFA] Revised C++ ABI abstraction patches

[J.T. Conklin]

>>>>> "Jim" == Jim Blandy <jimb@zwingli.cygnus.com> writes:
Jim> And besides, function calls are so slow.  Remember, GDB's performance
Jim> matters a lot --- it's used to debug real-time operating systems!
Jim> :(

I don't know whether you're being facetious, but IMHO avoiding
function call overhead is not a good argument for making a piece of
code a macro instead of a function.  I've seen many circumstances
where macros (or inlined functions) decrease the overall performance
of a system because the added code results in i-cache thrashing.

I think we should be addressing performance problems that are the
result of poor algorithms rather than spending any time bothering
with microoptimizations.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: [RFA] Revised C++ ABI abstraction patches

[Jim Blandy]

I was being thoroughly tongue-in-cheek.

But the joke is made a bit bitter by stuff like partial-stab.h, where
someone put 25k of code in a header file, which gets #included into
two different .c files, to save function call overhead.  Good call.
When you set a breakpoint in partial-stab.h, you have no idea which .c
file it's going into.  The best way to set a breakpoint in there is to
step to the place you want, and then do `break *$pc'.

(Who's the maintainer of that code, anyway?  ... Oh.)

jtc@redback.com (J.T. Conklin) writes:
> >>>>> "Jim" == Jim Blandy <jimb@zwingli.cygnus.com> writes:
> Jim> And besides, function calls are so slow.  Remember, GDB's performance
> Jim> matters a lot --- it's used to debug real-time operating systems!
> Jim> :(
> 
> I don't know whether you're being facetious, but IMHO avoiding
> function call overhead is not a good argument for making a piece of
> code a macro instead of a function.  I've seen many circumstances
> where macros (or inlined functions) decrease the overall performance
> of a system because the added code results in i-cache thrashing.
> 
> I think we should be addressing performance problems that are the
> result of poor algorithms rather than spending any time bothering
> with microoptimizations.

Hear, hear.

Re: [RFA] Revised C++ ABI abstraction patches

[Stan Shebs]

Jim Blandy wrote:
> 
> [...] stuff like partial-stab.h, where
> someone put 25k of code in a header file, which gets #included into
> two different .c files, to save function call overhead.  Good call.

Ah, youth... Once upon a time, when machines were much slower and
compilers did less optimization, the partial-stab.h trick was an
important speedup for psymtab reading.  It's quite possible that it
no longer matters, although I would suggest running some experiments
before acting on that assumption!  (GCC is 25x(!) slower than Metrowerks
because people add code to it without thinking much about the effect on
compile time.)

Stan

Re: [RFA] Revised C++ ABI abstraction patches

[Jim Blandy]

Stan Shebs <shebs@apple.com> writes:
> Jim Blandy wrote:
> > [...] stuff like partial-stab.h, where
> > someone put 25k of code in a header file, which gets #included into
> > two different .c files, to save function call overhead.  Good call.
> 
> Ah, youth... Once upon a time, when machines were much slower and
> compilers did less optimization, the partial-stab.h trick was an
> important speedup for psymtab reading.

Well, it's kind of dumb to second-guess experiences other people had
fifteen years ago, but still, I double-doubt this.  There's too much
other processing going on in that file --- as I've said, I've stepped
through it many a time --- for the function call overhead to be the
real issue.

Re: [RFA] Revised C++ ABI abstraction patches

[Andrew Cagney]

Jim Blandy wrote:
> 
> Stan Shebs <shebs@apple.com> writes:
> > Jim Blandy wrote:
> > > [...] stuff like partial-stab.h, where
> > > someone put 25k of code in a header file, which gets #included into
> > > two different .c files, to save function call overhead.  Good call.
> >
> > Ah, youth... Once upon a time, when machines were much slower and
> > compilers did less optimization, the partial-stab.h trick was an
> > important speedup for psymtab reading.
> 
> Well, it's kind of dumb to second-guess experiences other people had
> fifteen years ago, but still, I double-doubt this.  There's too much
> other processing going on in that file --- as I've said, I've stepped
> through it many a time --- for the function call overhead to be the
> real issue.

Yes.  Perhaphs the task of converting that header into functions should
be declared an ``obvious fix'' :-)

	Andrew

Re: [RFA] Revised C++ ABI abstraction patches

[Andrew Cagney]

Jim Blandy wrote:
> 
> Michael Elizabeth Chastain <chastain@cygnus.com> writes:
> > Lightly proofread, no obvious errors found.
> 
> Great.  That means all the bugs still there are non-obvious, and will
> take a long time to find.  Just make my day, will you.  (Thanks.)
> 
> > I would prefer constructor_prefix_p et al to be real functions rather
> > than macros.  When I single-step code in gdb, it's a lot easier to follow
> > real functions than macros.
> 
> I agree completely.  But it is not the standard practice (see target.h
> and elsewhere) and others don't seem to mind.  So I reined in my prima
> donna urges and left them as macros.

Standard pratice is to use functions.  Per the thread on the
xfer_memory() change - target.h will be fixed :-)

	enjoy,
		Andrew

Re: [RFA] Revised C++ ABI abstraction patches

[Daniel Berlin]

Andrew Cagney <ac131313@cygnus.com> writes:

> Jim Blandy wrote:
> > 
> > Michael Elizabeth Chastain <chastain@cygnus.com> writes:
> > > Lightly proofread, no obvious errors found.
> > 
> > Great.  That means all the bugs still there are non-obvious, and will
> > take a long time to find.  Just make my day, will you.  (Thanks.)
> > 
> > > I would prefer constructor_prefix_p et al to be real functions rather
> > > than macros.  When I single-step code in gdb, it's a lot easier to follow
> > > real functions than macros.
> > 
> > I agree completely.  But it is not the standard practice (see target.h
> > and elsewhere) and others don't seem to mind.  So I reined in my prima
> > donna urges and left them as macros.
> 
> Standard pratice is to use functions.  Per the thread on the
> xfer_memory() change - target.h will be fixed :-)

Can I make them static inline functions, and keep them in the header,
like the linux kernel does instead of macros?

Or should i just move them to functions in cp-abi.c?

--Dan

[RFA] Revised C++ ABI abstraction patches

[Jim Blandy]

I've gone through the set of patches Dan posted back in February,
incorporated the suggestions people made, and made some further
cleanups myself.  These patches depend on the demangler patches I just
posted to gcc-patches (and CC'd here).

They're not fit to be applied yet, since we don't yet automatically
detect whether the executable uses the V3 or V2 ABI.  Nonetheless, I'm
posting them here looking for comments, and so people can try them
out.

Certainly, if you are a maintainer, and you have objections to
something you see here, I'm all ears.


2001-03-15  Jim Blandy  <jimb@redhat.com>

	* cp-abi-gnu-v2.c (gnu_v2_destructor_prefix_p,
	gnu_v2_constructor_prefix_p, gnu_v2_vtable_prefix_p,
	init_gnu_v2_ops): Renamed from gnuv2_destructor_prefix_p,
	gnuv2_constructor_prefix_p, gnuv2_vtable_prefix_p,
	init_gnuv2_ops, to match general conventions used in GDB
	(words are separated by underscores).  Make these all static.
	Reformat definitions according to GNU coding standards.
	* cp-abi-gnu-v3.c (gnu_v3_destructor_prefix_p,
	gnu_v3_constructor_prefix_p, gnu_v3_vtable_prefix_p,
	init_gnu_v3_ops): Renamed from gnuv3_destructor_prefix_p,
	gnuv3_constructor_prefix_p, gnuv3_vtable_prefix_p,
	init_gnuv3_ops, to match general conventions used in GDB.
	Make these all static.  Reformat definitions according to GNU
	coding standards.

	* cp-abi-gnu-v2.c (gnuv2_vtable_prefix_p): Neaten up,
	following suggestion from Michael Chastain.

	* cp-abi-gnu-v3.c: Don't #include "gdb_regex.h" any more.
	Do #include "demangle.h".
	(gnuv3_destructor_prefix_p, gnuv3_constructor_prefix_p): 
	Use new functions exported by demangler to correctly recognize
	mangled names of constructors and destructors.
	* Makefile.in (cp-abi-gnu-v3.o): Remove gdb_regex.h from
	list of dependencies; add $(demangle_h).

	* cp-abi-gnu-v3.c (gnuv3_vtable_prefix_p): Fix sense of test
	of strncmp's return value.  (Thanks to Michael Chastain.)

	* cp-abi-gnu-v2.c, cp-abi-gnu-v3.c: Renamed from gnu-v2-abi.c
	and gnu-v3-abi.c, to show more clearly that they are
	implementations of cp-abi.h.
	* Makefile.in: Adjusted accordingly.

2001-02-20  Daniel Berlin  <dberlin@redhat.com>

	* Makefile.in (SFILES): Add gnu-v2-abi.c, gnu-v3-abi.c
	(COMMON_OBJS): Add gnu-v2-abi.o, gnu-v3-abi.o
	(gnu-v3-abi.o): Add.
	(gnu-v2-abi.o): Add.
	(symtab.o): Add cp-abi.h.
	(linespec.o): Add cp-abi.h.
	(dbxread.o): Add cp-abi.h.
	(c-typeprint.o): Add cp-abi.h.

	* cp-abi.h: New file. C++ abi abstraction

	* gnu-v2-abi.c: New file. C++ abi abstraction implementation for
	v2 abi.

	* gnu-v3-abi.c New file. C++ abi abstraction implementation for v3
	abi.

	* valops.c (value_rtti_type): VTBL_PREFIX_P -> vtbl_prefix_p.
	Add cp-abi.h to the include list.
	
	* symtab.c (gdb_mangle_name): DESTRUCTOR_PREFIX_P ->
	destructor_prefix_p.
	Replace hardcoded g++ v2 constructor name test with
	constructor_prefix_p. 
	Add cp-abi.h to the include list.
	
	* linespec.c (find_methods): Change SYMBOL_TYPE (sym_class) to
	CHECK_TYPEDEF (t), remove FIXME.
	Change method name comparison from STREQ to strcmp_iw.
	DESTRUCTOR_PREFIX_P -> destructor_prefix_p, fix test so it works
	(it was broken before, it was doing the reverse of what it
	should).
	Add cp-abi.h to include list.
	
	* dbxread.c (record_minimal_symbol): VTBL_PREFIX_P ->
	vtbl_prefix_p.
	Add cp-abi.h to include list.
	
	* c-typeprint.c (c_type_print_base): Remove hardcoded g++ v2
	destructor/constructor name test, replace with
	destructor_prefix_p, constructor_prefix_p. 
	Change STREQN (method_name, "~", 1) to method_name[0] == '~'.
	Add cp-abi.h to include list

	* jv-typeprint.c (java_type_print_base): Remove hardcoded g++ v2
	destructor/constructor name test, replace with
	destructor_prefix_p, constructor_prefix_p.
	
	* symtab.h: Remove VTBL_PREFIX_P macro.
	Remove DESTRUCTOR_PREFIX_P macro.

Index: gdb/Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.72
diff -c -c -3 -p -r1.72 Makefile.in
*** gdb/Makefile.in	2001/03/10 06:17:20	1.72
--- gdb/Makefile.in	2001/03/15 09:40:05
*************** SFILES = ax-general.c ax-gdb.c bcache.c 
*** 539,545 ****
  	tui/tuiStack.c tui/tuiStack.h tui/tuiWin.c tui/tuiWin.h \
  	tui/tui-file.h tui/tui-file.c \
  	ui-file.h ui-file.c \
! 	frame.c
  
  LINTFILES = $(SFILES) $(YYFILES) $(CONFIG_SRCS) init.c
  
--- 539,546 ----
  	tui/tuiStack.c tui/tuiStack.h tui/tuiWin.c tui/tuiWin.h \
  	tui/tui-file.h tui/tui-file.c \
  	ui-file.h ui-file.c \
! 	frame.c \
! 	cp-abi-gnu-v2.c cp-abi-gnu-v3.c
  
  LINTFILES = $(SFILES) $(YYFILES) $(CONFIG_SRCS) init.c
  
*************** floatformat_h =	$(INCLUDE_DIR)/floatform
*** 553,558 ****
--- 554,560 ----
  bfd_h =		$(BFD_DIR)/bfd.h
  dis-asm_h =	$(INCLUDE_DIR)/dis-asm.h 
  remote-sim_h =	$(INCLUDE_DIR)/remote-sim.h
+ demangle_h =    $(INCLUDE_DIR)/demangle.h
  
  dcache_h = dcache.h
  remote_utils_h = $(dcache_h) serial.h target.h remote-utils.h $(remote-sim_h)
*************** value_h =	value.h $(symtab_h) $(gdbtypes
*** 584,589 ****
--- 586,592 ----
  breakpoint_h =	breakpoint.h $(frame_h) $(value_h)
  
  command_h =	command.h
+ cp_abi_h =      cp-abi.h
  gdbcmd_h =	gdbcmd.h $(command_h)
  call_cmds_h =	call-cmds.h
  regcache_h =	regcache.h
*************** COMMON_OBS = version.o blockframe.o brea
*** 685,691 ****
  	c-valprint.o cp-valprint.o ch-valprint.o f-valprint.o m2-valprint.o \
  	nlmread.o serial.o mdebugread.o os9kread.o top.o utils.o \
  	ui-file.o tui-file.o \
! 	frame.o
  
  OBS = $(COMMON_OBS) $(ANNOTATE_OBS)
  
--- 688,695 ----
  	c-valprint.o cp-valprint.o ch-valprint.o f-valprint.o m2-valprint.o \
  	nlmread.o serial.o mdebugread.o os9kread.o top.o utils.o \
  	ui-file.o tui-file.o \
! 	frame.o \
! 	cp-abi-gnu-v2.o cp-abi-gnu-v3.o
  
  OBS = $(COMMON_OBS) $(ANNOTATE_OBS)
  
*************** c-lang.o: c-lang.c c-lang.h $(defs_h) $(
*** 1228,1234 ****
  
  c-typeprint.o: c-typeprint.c c-lang.h $(defs_h) $(expression_h) \
  	$(gdbcmd_h) $(gdbcore_h) $(gdbtypes_h) language.h $(symtab_h) \
! 	target.h typeprint.h $(value_h) gdb_string.h
  
  c-valprint.o: c-valprint.c $(defs_h) $(expression_h) $(gdbtypes_h) \
  	language.h $(symtab_h) valprint.h $(value_h)
--- 1232,1238 ----
  
  c-typeprint.o: c-typeprint.c c-lang.h $(defs_h) $(expression_h) \
  	$(gdbcmd_h) $(gdbcore_h) $(gdbtypes_h) language.h $(symtab_h) \
! 	target.h typeprint.h $(value_h) gdb_string.h $(cp_abi_h)
  
  c-valprint.o: c-valprint.c $(defs_h) $(expression_h) $(gdbtypes_h) \
  	language.h $(symtab_h) valprint.h $(value_h)
*************** dcache.o: dcache.c $(dcache_h) $(defs_h)
*** 1293,1299 ****
  dbxread.o: dbxread.c $(breakpoint_h) buildsym.h $(command_h) \
  	complaints.h $(defs_h) $(expression_h) gdb-stabs.h $(gdbcore_h) \
  	$(gdbtypes_h) language.h objfiles.h partial-stab.h stabsread.h \
! 	symfile.h $(symtab_h) target.h gdb_string.h
  
  delta68-nat.o: delta68-nat.c $(defs_h)
  
--- 1297,1303 ----
  dbxread.o: dbxread.c $(breakpoint_h) buildsym.h $(command_h) \
  	complaints.h $(defs_h) $(expression_h) gdb-stabs.h $(gdbcore_h) \
  	$(gdbtypes_h) language.h objfiles.h partial-stab.h stabsread.h \
! 	symfile.h $(symtab_h) target.h gdb_string.h $(cp_abi_h)
  
  delta68-nat.o: delta68-nat.c $(defs_h)
  
*************** arch-utils.o: arch-utils.c $(defs_h) $(b
*** 1452,1458 ****
  
  gdbtypes.o: gdbtypes.c $(bfd_h) complaints.h $(defs_h) $(expression_h) \
  	$(gdbtypes_h) language.h objfiles.h symfile.h $(symtab_h) target.h \
! 	$(value_h) gdb_string.h wrapper.h
  
  go32-nat.o: go32-nat.c $(defs_h) $(inferior_h) gdb_wait.h $(gdbcore_h) \
  	$(command_h) $(floatformat_h) target.h i387-nat.h $(regcache_h)
--- 1456,1462 ----
  
  gdbtypes.o: gdbtypes.c $(bfd_h) complaints.h $(defs_h) $(expression_h) \
  	$(gdbtypes_h) language.h objfiles.h symfile.h $(symtab_h) target.h \
! 	$(value_h) gdb_string.h wrapper.h $(cp_abi_h)
  
  go32-nat.o: go32-nat.c $(defs_h) $(inferior_h) gdb_wait.h $(gdbcore_h) \
  	$(command_h) $(floatformat_h) target.h i387-nat.h $(regcache_h)
*************** go32-nat.o: go32-nat.c $(defs_h) $(infer
*** 1460,1465 ****
--- 1464,1474 ----
  gnu-nat.o: process_reply_S.h exc_request_S.h notify_S.h msg_reply_S.h \
  	exc_request_U.h msg_U.h gnu-nat.h
  
+ cp-abi-gnu-v3.o: cp-abi-gnu-v3.c $(cp_abi_h) $(defs) gdb_string.h \
+ 	$(demangle_h)
+ 
+ cp-abi-gnu-v2.o: cp-abi-gnu-v2.c $(cp_abi_h) $(defs) gdb_regex.h gdb_string.h
+ 
  h8300-tdep.o: h8300-tdep.c $(defs_h) $(frame_h) $(symtab_h) $(regcache_h)
  
  h8500-tdep.o: h8500-tdep.c $(bfd_h) $(dis-asm_h) $(defs_h) \
*************** jv-lang.o: jv-lang.c $(bfd_h) $(defs_h) 
*** 1554,1564 ****
  	gdb_string.h $(value_h) c-lang.h jv-lang.h $(gdbcore_h)
  
  jv-typeprint.o: jv-typeprint.c $(bfd_h) $(defs_h) $(symtab_h) $(gdbtypes_h) \
! 	$(value_h) $(INCLUDE_DIR)/demangle.h jv-lang.h gdb_string.h \
  	typeprint.h c-lang.h
  
  jv-valprint.o: jv-valprint.c $(bfd_h) $(defs_h) $(symtab_h) $(gdbtypes_h) \
! 	$(expression_h) $(value_h) $(INCLUDE_DIR)/demangle.h valprint.h \
  	language.h jv-lang.h c-lang.h gdbcore.h annotate.h
  
  kod.o: kod.c $(defs_h) $(command_h) $(gdbcmd_h) target.h gdb_string.h kod.h
--- 1563,1573 ----
  	gdb_string.h $(value_h) c-lang.h jv-lang.h $(gdbcore_h)
  
  jv-typeprint.o: jv-typeprint.c $(bfd_h) $(defs_h) $(symtab_h) $(gdbtypes_h) \
! 	$(value_h) $(demangle_h) jv-lang.h gdb_string.h \
  	typeprint.h c-lang.h
  
  jv-valprint.o: jv-valprint.c $(bfd_h) $(defs_h) $(symtab_h) $(gdbtypes_h) \
! 	$(expression_h) $(value_h) $(demangle_h) valprint.h \
  	language.h jv-lang.h c-lang.h gdbcore.h annotate.h
  
  kod.o: kod.c $(defs_h) $(command_h) $(gdbcmd_h) target.h gdb_string.h kod.h
*************** symmisc.o: symmisc.c $(bfd_h) $(breakpoi
*** 1962,1972 ****
  symtab.o: symtab.c call-cmds.h $(defs_h) $(expression_h) $(frame_h) \
  	$(gdbcmd_h) $(gdbcore_h) $(gdbtypes_h) language.h objfiles.h \
  	gnu-regex.h symfile.h $(symtab_h) target.h $(value_h) \
! 	gdb_string.h linespec.h
  
  linespec.o: linespec.c linespec.h $(defs_h) $(frame_h) $(value_h) \
  	objfiles.h symfile.h completer.h $(symtab_h) \
! 	$(INCLUDE_DIR)/demangle.h command.h
  
  tic80-tdep.o: tic80-tdep.c $(defs_h) $(regcache_h)
  
--- 1971,1981 ----
  symtab.o: symtab.c call-cmds.h $(defs_h) $(expression_h) $(frame_h) \
  	$(gdbcmd_h) $(gdbcore_h) $(gdbtypes_h) language.h objfiles.h \
  	gnu-regex.h symfile.h $(symtab_h) target.h $(value_h) \
! 	gdb_string.h linespec.h $(cp_abi_h)
  
  linespec.o: linespec.c linespec.h $(defs_h) $(frame_h) $(value_h) \
  	objfiles.h symfile.h completer.h $(symtab_h) \
! 	$(demangle_h) command.h $(cp_abi_h)
  
  tic80-tdep.o: tic80-tdep.c $(defs_h) $(regcache_h)
  
Index: gdb/c-typeprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-typeprint.c,v
retrieving revision 1.6
diff -c -c -3 -p -r1.6 c-typeprint.c
*** gdb/c-typeprint.c	2001/03/07 02:57:08	1.6
--- gdb/c-typeprint.c	2001/03/15 09:40:06
***************
*** 38,43 ****
--- 38,44 ----
  
  #include "gdb_string.h"
  #include <errno.h>
+ #include "cp-abi.h"
  
  /* Flag indicating target was compiled by HP compiler */
  extern int hp_som_som_object_present;
*************** c_type_print_base (struct type *type, st
*** 902,912 ****
  		{
  		  char *physname = TYPE_FN_FIELD_PHYSNAME (f, j);
  		  int is_full_physname_constructor =
! 		  ((physname[0] == '_' && physname[1] == '_'
! 		    && strchr ("0123456789Qt", physname[2]))
! 		   || STREQN (physname, "__ct__", 6)
! 		   || DESTRUCTOR_PREFIX_P (physname)
! 		   || STREQN (physname, "__dt__", 6));
  
  		  QUIT;
  		  if (TYPE_FN_FIELD_PROTECTED (f, j))
--- 903,912 ----
  		{
  		  char *physname = TYPE_FN_FIELD_PHYSNAME (f, j);
  		  int is_full_physname_constructor =
! 		   constructor_prefix_p (physname) 
! 		   || destructor_prefix_p (physname)
! 		   || method_name[0] == '~';
! 		   
  
  		  QUIT;
  		  if (TYPE_FN_FIELD_PROTECTED (f, j))
Index: gdb/cp-abi-gnu-v2.c
===================================================================
RCS file: cp-abi-gnu-v2.c
diff -N cp-abi-gnu-v2.c
*** gdb/cp-abi-gnu-v2.c	Tue May  5 13:32:27 1998
--- gdb/cp-abi-gnu-v2.c	Thu Mar 15 01:40:06 2001
***************
*** 0 ****
--- 1,74 ----
+ /* Abstraction of GNU v2 abi.
+    Contributed by Daniel Berlin <dberlin@redhat.com>
+    Copyright 2001 Free Software Foundation, Inc.
+ 
+    This file is part of GDB.
+ 
+    This program is free software; you can redistribute it and/or
+    modify
+    it under the terms of the GNU General Public License as published
+    by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+ 
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+ 
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place - Suite 330,
+    Boston, MA 02111-1307, USA.  */
+ 
+ #include "defs.h"
+ #include "cp-abi.h"
+ #include "gdb_regex.h"
+ #include "gdb_string.h"
+ #include <ctype.h>
+ 
+ struct cp_abi_ops gnu_v2_abi_ops;
+ 
+ static int
+ gnu_v2_destructor_prefix_p (const char * name)
+ {
+   return ((name[0] == '_' && is_cplus_marker (name[1]) && name[2] == '_')  
+ 	  || strncmp(name, "__dt__", 6) == 0);
+ }
+ 
+ static int
+ gnu_v2_constructor_prefix_p (const char * name)
+ { 
+   return ((name[0] == '_' && name[1] == '_'  
+ 	   && (isdigit (name[2]) || strchr ("Qt", name[2]))) 
+ 	  || strncmp(name, "__ct__", 6) == 0);
+ }
+ 
+ static int
+ gnu_v2_vtable_prefix_p (const char * name)
+ {
+   return ((strncmp (name, "_VT", 3) == 0 && is_cplus_marker (name[3]))
+ 	  || (strncmp (name, "_vt", 3) == 0 && is_cplus_marker (name[3]))
+ 	  || (strncmp (name, "__vt_", 5) == 0));
+ }
+ 
+ static void
+ init_gnu_v2_ops (void)
+ {
+   gnu_v2_abi_ops.cpo_shortname = "gnu-v2";
+   gnu_v2_abi_ops.cpo_longname = "GNU G++ Version 2 ABI";
+   gnu_v2_abi_ops.cpo_doc = "G++ Version 2 ABI";
+   gnu_v2_abi_ops.cpo_destructor_prefix_p = gnu_v2_destructor_prefix_p;
+   gnu_v2_abi_ops.cpo_constructor_prefix_p = gnu_v2_constructor_prefix_p;
+   gnu_v2_abi_ops.cpo_vtable_prefix_p = gnu_v2_vtable_prefix_p;
+ }
+ 
+ 
+ /* struct cp_abi_ops current_cp_abi; */
+ void
+ _initialize_gnu_v2_abi (void)
+ {
+   init_gnu_v2_ops();
+   /* current_cp_abi = gnu_v2_abi_ops; */
+ }
+ 
Index: gdb/cp-abi-gnu-v3.c
===================================================================
RCS file: cp-abi-gnu-v3.c
diff -N cp-abi-gnu-v3.c
*** gdb/cp-abi-gnu-v3.c	Tue May  5 13:32:27 1998
--- gdb/cp-abi-gnu-v3.c	Thu Mar 15 01:40:06 2001
***************
*** 0 ****
--- 1,98 ----
+ /* Abstraction of GNU v3 abi.
+    Contributed by Daniel Berlin <dberlin@redhat.com>
+    Copyright 2001 Free Software Foundation, Inc.
+ 
+    This file is part of GDB.
+ 
+    This program is free software; you can redistribute it and/or
+    modify
+    it under the terms of the GNU General Public License as published
+    by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+ 
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+ 
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place - Suite 330,
+    Boston, MA 02111-1307, USA.  */
+ 
+ #include "defs.h"
+ #include "cp-abi.h"
+ #include "gdb_string.h"
+ #include "demangle.h"
+ 
+ struct cp_abi_ops gnu_v3_abi_ops;
+ 
+ 
+ static int
+ gnu_v3_destructor_prefix_p (const char * name)
+ {
+   /* A quick false positive test: all destructors should start with
+      "_Z", and end with "D[012]Ev".  */
+   if (! strncmp (name, "_Z", 2))
+     {
+       int length = strlen (name);
+ 
+       if (! strcmp (name + length - 2, "Ev")
+ 	  && ('0' <= name[length - 3] && name[length - 3] <= '2')
+ 	  && name[length - 4] == 'D')
+ 	return is_gnu_v3_mangled_destructor (name) != 0;
+     }
+ 
+   return 0;
+ }
+ 
+ 
+ static int
+ gnu_v3_constructor_prefix_p (const char * name)
+ {
+   /* A quick false positive test: all constructors should start with _Z,
+      and contain a match for "C[123]".  */
+   if (! strncmp (name, "_Z", 2))
+     {
+       const char *scan = name;
+ 
+       while ((scan = strchr (scan, 'C')) != 0)
+ 	{
+ 	  if ('1' <= scan[1] && scan[1] <= '3')
+ 	    return is_gnu_v3_mangled_constructor (name) != 0;	    
+ 
+ 	  scan++;
+ 	}
+     }
+ 
+   return 0;
+ }
+ 
+ 
+ static int
+ gnu_v3_vtable_prefix_p (const char * name)
+ {
+   return strncmp (name, "_ZTV", 4) == 0;
+ }
+ 
+ 
+ void
+ init_gnu_v3_ops (void)
+ {
+   gnu_v3_abi_ops.cpo_shortname = "gnu-v3";
+   gnu_v3_abi_ops.cpo_longname = "GNU G++ Version 3 ABI";
+   gnu_v3_abi_ops.cpo_doc = "G++ Version 3 ABI";
+   gnu_v3_abi_ops.cpo_destructor_prefix_p = gnu_v3_destructor_prefix_p;
+   gnu_v3_abi_ops.cpo_constructor_prefix_p = gnu_v3_constructor_prefix_p;
+   gnu_v3_abi_ops.cpo_vtable_prefix_p = gnu_v3_vtable_prefix_p;
+ 
+ }
+ struct cp_abi_ops current_cp_abi;
+ void
+ _initialize_gnu_v3_abi (void)
+ {
+   init_gnu_v3_ops();
+   current_cp_abi = gnu_v3_abi_ops;
+ }
+ 
Index: gdb/cp-abi.h
===================================================================
RCS file: cp-abi.h
diff -N cp-abi.h
*** gdb/cp-abi.h	Tue May  5 13:32:27 1998
--- gdb/cp-abi.h	Thu Mar 15 01:40:06 2001
***************
*** 0 ****
--- 1,75 ----
+ /* Abstraction of various C++ ABI's we support, and the info we need
+    to get from them.
+    Contributed by Daniel Berlin <dberlin@redhat.com>
+    Copyright 2001 Free Software Foundation, Inc.
+ 
+    This file is part of GDB.
+ 
+    This program is free software; you can redistribute it and/or
+    modify
+    it under the terms of the GNU General Public License as published
+    by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+ 
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+ 
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place - Suite 330,
+    Boston, MA 02111-1307, USA.  */
+ 
+ #ifndef CP_ABI_H_
+ #define CP_ABI_H_ 1
+ 
+ /* Following the target ops as a reference */
+ struct cp_abi_ops
+ {
+   const char *cpo_shortname;
+   const char *cpo_longname;
+   const char *cpo_doc;
+ 
+ 
+   /* FIXME: prefix is a misnomer, because not all ABI's do
+      constructors by prefix. However, we don't want these names to be
+      not understandable, and ca_mangled_name_is_constructor_p is a
+      little long. Ideas?
+   */
+   /* Determine if the given *mangled* name is a destructor. Might
+   change to demangled name in the future, but not without warning. It
+   depends on whether or not this ends up being completely used in the
+   old GNU abi, or if it was really needed somewhere else */
+   
+   int (*cpo_destructor_prefix_p) (const char *name); 
+   
+   /* Determine if a given *mangled* name is a constructor. Same
+      warning as for destructor functions.*/
+   int (*cpo_constructor_prefix_p) (const char *name);
+ 
+   /* Determine if a given *mangled* name is a vtable. Same warning as
+      for constructors and destructor functions. */
+   int (*cpo_vtable_prefix_p) (const char *name);
+ 
+   /* Determine if a given *mangled* name is an operator. Same warning
+      as all of the others */
+   int (*cpo_operator_prefix_p) (const char *name);
+ };
+ 
+ extern struct cp_abi_ops current_cp_abi;
+ 
+ #define constructor_prefix_p(NAME) \
+ (*current_cp_abi.cpo_constructor_prefix_p)(NAME)
+ 
+ #define destructor_prefix_p(NAME) \
+ (*current_cp_abi.cpo_destructor_prefix_p)(NAME)
+ 
+ #define vtbl_prefix_p(NAME) \
+ (*current_cp_abi.cpo_vtable_prefix_p)(NAME)
+ 
+ #define operator_prefix_p(NAME) \
+ (*current_cp_abi.cpo_operator_prefix_p)(NAME)
+ #endif
+ 
Index: gdb/dbxread.c
===================================================================
RCS file: /cvs/src/src/gdb/dbxread.c,v
retrieving revision 1.15
diff -c -c -3 -p -r1.15 dbxread.c
*** gdb/dbxread.c	2001/03/07 02:57:08	1.15
--- gdb/dbxread.c	2001/03/15 09:40:08
***************
*** 58,63 ****
--- 58,64 ----
  #include "demangle.h"
  #include "language.h"		/* Needed inside partial-stab.h */
  #include "complaints.h"
+ #include "cp-abi.h"
  
  #include "aout/aout64.h"
  #include "aout/stab_gnu.h"	/* We always use GNU stabs, not native, now */
*************** record_minimal_symbol (char *name, CORE_
*** 514,520 ****
  	char *tempstring = name;
  	if (tempstring[0] == bfd_get_symbol_leading_char (objfile->obfd))
  	  ++tempstring;
! 	if (VTBL_PREFIX_P ((tempstring)))
  	  ms_type = mst_data;
        }
        section = SECT_OFF_DATA (objfile);
--- 515,521 ----
  	char *tempstring = name;
  	if (tempstring[0] == bfd_get_symbol_leading_char (objfile->obfd))
  	  ++tempstring;
! 	if (vtbl_prefix_p (tempstring))
  	  ms_type = mst_data;
        }
        section = SECT_OFF_DATA (objfile);
Index: gdb/gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.18
diff -c -c -3 -p -r1.18 gdbtypes.c
*** gdb/gdbtypes.c	2001/03/07 02:57:08	1.18
--- gdb/gdbtypes.c	2001/03/15 09:40:09
***************
*** 35,40 ****
--- 35,41 ----
  #include "complaints.h"
  #include "gdbcmd.h"
  #include "wrapper.h"
+ #include "cp-abi.h"
  
  /* These variables point to the objects
     representing the predefined C data types.  */
*************** get_destructor_fn_field (struct type *t,
*** 1027,1033 ****
  
        for (j = 0; j < TYPE_FN_FIELDLIST_LENGTH (t, i); j++)
  	{
! 	  if (DESTRUCTOR_PREFIX_P (TYPE_FN_FIELD_PHYSNAME (f, j)))
  	    {
  	      *method_indexp = i;
  	      *field_indexp = j;
--- 1028,1034 ----
  
        for (j = 0; j < TYPE_FN_FIELDLIST_LENGTH (t, i); j++)
  	{
! 	  if (destructor_prefix_p (TYPE_FN_FIELD_PHYSNAME (f, j)) != 0)
  	    {
  	      *method_indexp = i;
  	      *field_indexp = j;
Index: gdb/jv-typeprint.c
===================================================================
RCS file: /cvs/src/src/gdb/jv-typeprint.c,v
retrieving revision 1.4
diff -c -c -3 -p -r1.4 jv-typeprint.c
*** gdb/jv-typeprint.c	2001/03/06 08:21:09	1.4
--- gdb/jv-typeprint.c	2001/03/15 09:40:09
***************
*** 28,34 ****
  #include "gdb_string.h"
  #include "typeprint.h"
  #include "c-lang.h"
! 
  /* Local functions */
  
  static void java_type_print_base (struct type * type,
--- 28,34 ----
  #include "gdb_string.h"
  #include "typeprint.h"
  #include "c-lang.h"
! #include "cp-abi.h"
  /* Local functions */
  
  static void java_type_print_base (struct type * type,
*************** java_type_print_base (struct type *type,
*** 224,235 ****
  
  		  physname = TYPE_FN_FIELD_PHYSNAME (f, j);
  
! 		  is_full_physname_constructor =
! 		    ((physname[0] == '_' && physname[1] == '_'
! 		      && strchr ("0123456789Qt", physname[2]))
! 		     || STREQN (physname, "__ct__", 6)
! 		     || DESTRUCTOR_PREFIX_P (physname)
! 		     || STREQN (physname, "__dt__", 6));
  
  		  QUIT;
  
--- 224,230 ----
  
  		  physname = TYPE_FN_FIELD_PHYSNAME (f, j);
  
! 		  is_full_physname_constructor = constructor_prefix_p (physname) != 0 || destructor_prefix_p (physname) != 0;
  
  		  QUIT;
  
Index: gdb/linespec.c
===================================================================
RCS file: /cvs/src/src/gdb/linespec.c,v
retrieving revision 1.6
diff -c -c -3 -p -r1.6 linespec.c
*** gdb/linespec.c	2001/03/14 18:36:45	1.6
--- gdb/linespec.c	2001/03/15 09:40:10
***************
*** 29,34 ****
--- 29,35 ----
  #include "demangle.h"
  #include "value.h"
  #include "completer.h"
+ #include "cp-abi.h"
  
  /* Prototype for one function in parser-defs.h,
     instead of including that entire file. */
*************** find_methods (struct type *t, char *name
*** 119,127 ****
      {
        int method_counter;
  
!       /* FIXME: Shouldn't this just be CHECK_TYPEDEF (t)?  */
!       t = SYMBOL_TYPE (sym_class);
! 
        /* Loop over each method name.  At this level, all overloads of a name
           are counted as a single name.  There is an inner loop which loops over
           each overload.  */
--- 120,126 ----
      {
        int method_counter;
  
!       CHECK_TYPEDEF (t);
        /* Loop over each method name.  At this level, all overloads of a name
           are counted as a single name.  There is an inner loop which loops over
           each overload.  */
*************** find_methods (struct type *t, char *name
*** 144,150 ****
  		method_name = dem_opname;
  	    }
  
! 	  if (STREQ (name, method_name))
  	    /* Find all the overloaded methods with that name.  */
  	    for (field_counter = TYPE_FN_FIELDLIST_LENGTH (t, method_counter) - 1;
  		 field_counter >= 0;
--- 143,149 ----
  		method_name = dem_opname;
  	    }
  
! 	  if (strcmp_iw (name, method_name) == 0)
  	    /* Find all the overloaded methods with that name.  */
  	    for (field_counter = TYPE_FN_FIELDLIST_LENGTH (t, method_counter) - 1;
  		 field_counter >= 0;
*************** find_methods (struct type *t, char *name
*** 168,176 ****
  		  }
  		else
  		  phys_name = TYPE_FN_FIELD_PHYSNAME (f, field_counter);
! 
  		/* Destructor is handled by caller, dont add it to the list */
! 		if (DESTRUCTOR_PREFIX_P (phys_name))
  		  continue;
  
  		sym_arr[i1] = lookup_symbol (phys_name,
--- 167,175 ----
  		  }
  		else
  		  phys_name = TYPE_FN_FIELD_PHYSNAME (f, field_counter);
! 		
  		/* Destructor is handled by caller, dont add it to the list */
! 		if (destructor_prefix_p (phys_name) != 0)
  		  continue;
  
  		sym_arr[i1] = lookup_symbol (phys_name,
Index: gdb/symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.32
diff -c -c -3 -p -r1.32 symtab.c
*** gdb/symtab.c	2001/03/06 08:21:17	1.32
--- gdb/symtab.c	2001/03/15 09:40:12
***************
*** 45,51 ****
  #include "gdb_string.h"
  #include "gdb_stat.h"
  #include <ctype.h>
! 
  /* Prototype for one function in parser-defs.h,
     instead of including that entire file. */
  
--- 45,51 ----
  #include "gdb_string.h"
  #include "gdb_stat.h"
  #include <ctype.h>
! #include "cp-abi.h"
  /* Prototype for one function in parser-defs.h,
     instead of including that entire file. */
  
*************** gdb_mangle_name (struct type *type, int 
*** 288,294 ****
    int is_full_physname_constructor;
  
    int is_constructor;
!   int is_destructor = DESTRUCTOR_PREFIX_P (physname);
    /* Need a new type prefix.  */
    char *const_prefix = method->is_const ? "C" : "";
    char *volatile_prefix = method->is_volatile ? "V" : "";
--- 288,294 ----
    int is_full_physname_constructor;
  
    int is_constructor;
!   int is_destructor = destructor_prefix_p (physname);
    /* Need a new type prefix.  */
    char *const_prefix = method->is_const ? "C" : "";
    char *volatile_prefix = method->is_volatile ? "V" : "";
*************** gdb_mangle_name (struct type *type, int 
*** 298,307 ****
    if (OPNAME_PREFIX_P (field_name))
      return xstrdup (physname);
  
!   is_full_physname_constructor =
!     ((physname[0] == '_' && physname[1] == '_' &&
!       (isdigit (physname[2]) || physname[2] == 'Q' || physname[2] == 't'))
!      || (strncmp (physname, "__ct", 4) == 0));
  
    is_constructor =
      is_full_physname_constructor || (newname && STREQ (field_name, newname));
--- 298,304 ----
    if (OPNAME_PREFIX_P (field_name))
      return xstrdup (physname);
  
!   is_full_physname_constructor = constructor_prefix_p (physname);
  
    is_constructor =
      is_full_physname_constructor || (newname && STREQ (field_name, newname));
Index: gdb/symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.20
diff -c -c -3 -p -r1.20 symtab.h
*** gdb/symtab.h	2001/03/07 02:57:08	1.20
--- gdb/symtab.h	2001/03/15 09:40:13
*************** struct partial_symtab
*** 1051,1075 ****
  #define OPNAME_PREFIX_P(NAME) \
    (!strncmp (NAME, "operator", 8))
  
- /* Macro that yields non-zero value iff NAME is the prefix for C++ vtbl
-    names.  Note that this macro is g++ specific (FIXME).
-    '_vt$' is the old cfront-style vtables; '_VT$' is the new
-    style, using thunks (where '$' is really CPLUS_MARKER). */
- 
- #define VTBL_PREFIX_P(NAME) \
-   (((NAME)[0] == '_' \
-    && (((NAME)[1] == 'V' && (NAME)[2] == 'T') \
-        || ((NAME)[1] == 'v' && (NAME)[2] == 't')) \
-    && is_cplus_marker ((NAME)[3])) || ((NAME)[0]=='_' && (NAME)[1]=='_' \
-    && (NAME)[2]=='v' && (NAME)[3]=='t' && (NAME)[4]=='_'))
- 
- /* Macro that yields non-zero value iff NAME is the prefix for C++ destructor
-    names.  Note that this macro is g++ specific (FIXME).  */
- 
- #define DESTRUCTOR_PREFIX_P(NAME) \
-   ((NAME)[0] == '_' && is_cplus_marker ((NAME)[1]) && (NAME)[2] == '_')
  \f
- 
  /* External variables and functions for the objects described above. */
  
  /* This symtab variable specifies the current file for printing source lines */
--- 1051,1057 ----
Index: gdb/valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.33
diff -c -c -3 -p -r1.33 valops.c
*** gdb/valops.c	2001/03/06 08:21:18	1.33
--- gdb/valops.c	2001/03/15 09:40:15
***************
*** 31,36 ****
--- 31,37 ----
  #include "language.h"
  #include "gdbcmd.h"
  #include "regcache.h"
+ #include "cp-abi.h"
  
  #include <errno.h>
  #include "gdb_string.h"
*************** value_rtti_type (value_ptr v, int *full,
*** 3296,3302 ****
  
        /* Try to find a symbol that is the vtable */
        minsym=lookup_minimal_symbol_by_pc(vtbl);
!       if (minsym==NULL || (demangled_name=SYMBOL_NAME(minsym))==NULL || !VTBL_PREFIX_P(demangled_name))
  	return NULL;
  
        /* If we just skip the prefix, we get screwed by namespaces */
--- 3297,3303 ----
  
        /* Try to find a symbol that is the vtable */
        minsym=lookup_minimal_symbol_by_pc(vtbl);
!       if (minsym==NULL || (demangled_name=SYMBOL_NAME(minsym))==NULL || !vtbl_prefix_p(demangled_name))
  	return NULL;
  
        /* If we just skip the prefix, we get screwed by namespaces */

Re: [RFA] Revised C++ ABI abstraction patches

[Eli Zaretskii]

On Thu, 15 Mar 2001, Jim Blandy wrote:

> They're not fit to be applied yet, since we don't yet automatically
> detect whether the executable uses the V3 or V2 ABI.

If it's important for users to be able to support the new ABI, you could 
add a command which tells GDB which ABI to expect, no?

> 	* cp-abi-gnu-v2.c (gnu_v2_destructor_prefix_p,
[...]
> 	(gnu-v3-abi.o): Add.
> 	(gnu-v2-abi.o): Add.

So what is it: cp-abi-gnu-v2 or gnu-v2-abi?  I prefer the latter, and I 
thought that was the conclusion of the earlier discussions about that.

Re: [RFA] Revised C++ ABI abstraction patches

[Fernando Nasser]

What about a configuration option  --with-v3abi (or something of a
sort)?

Default no for 5.1, default on afterwards.

Fernando

Eli Zaretskii wrote:
> 
> On Thu, 15 Mar 2001, Jim Blandy wrote:
> 
> > They're not fit to be applied yet, since we don't yet automatically
> > detect whether the executable uses the V3 or V2 ABI.
> 
> If it's important for users to be able to support the new ABI, you could
> add a command which tells GDB which ABI to expect, no?
> 
> >       * cp-abi-gnu-v2.c (gnu_v2_destructor_prefix_p,
> [...]
> >       (gnu-v3-abi.o): Add.
> >       (gnu-v2-abi.o): Add.
> 
> So what is it: cp-abi-gnu-v2 or gnu-v2-abi?  I prefer the latter, and I
> thought that was the conclusion of the earlier discussions about that.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Revised C++ ABI abstraction patches

[Daniel Berlin]

No need, it can be auto-detected.

I just sent jim my revised revised revised patch, whic, among other
things, lets you switch between the ABI's on the fly.
I have one more function that needs abstracting before i submit it to 
gdb-patches.

--Dan


On Thu, 15 Mar 2001, Fernando Nasser wrote:

> What about a configuration option  --with-v3abi (or something of a
> sort)?
> 
> Default no for 5.1, default on afterwards.
> 
> Fernando
> 
> Eli Zaretskii wrote:
> > 
> > On Thu, 15 Mar 2001, Jim Blandy wrote:
> > 
> > > They're not fit to be applied yet, since we don't yet automatically
> > > detect whether the executable uses the V3 or V2 ABI.
> > 
> > If it's important for users to be able to support the new ABI, you could
> > add a command which tells GDB which ABI to expect, no?
> > 
> > >       * cp-abi-gnu-v2.c (gnu_v2_destructor_prefix_p,
> > [...]
> > >       (gnu-v3-abi.o): Add.
> > >       (gnu-v2-abi.o): Add.
> > 
> > So what is it: cp-abi-gnu-v2 or gnu-v2-abi?  I prefer the latter, and I
> > thought that was the conclusion of the earlier discussions about that.
> 
> -- 
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9
> 

Re: [RFA] Revised C++ ABI abstraction patches

[Jim Blandy]

Eli Zaretskii <eliz@is.elta.co.il> writes:
> > 	* cp-abi-gnu-v2.c (gnu_v2_destructor_prefix_p,
> [...]
> > 	(gnu-v3-abi.o): Add.
> > 	(gnu-v2-abi.o): Add.
> 
> So what is it: cp-abi-gnu-v2 or gnu-v2-abi?  I prefer the latter, and I 
> thought that was the conclusion of the earlier discussions about that.

gnu-v[23]-abi were the names originally used in Daniel's patch.  I
changed them to cp-abi-gnu-v[23], for the reasons explained in the
ChangeLog entry provided with the patch:

	* cp-abi-gnu-v2.c, cp-abi-gnu-v3.c: Renamed from gnu-v2-abi.c
	and gnu-v3-abi.c, to show more clearly that they are
	implementations of cp-abi.h.
	* Makefile.in: Adjusted accordingly.

The names `gnu-v[23]-abi' just indicate that they're implementations
of some ABI, but the files are actually specifically dealing with C++
ABI's.  It's not meaningful to talk about an ABI without knowing the
source language, since an ABI is a binding between a particular source
language and a particular machine language.

For example, if we were to add Fortran support to GDB, each Fortran
compiler seems to have its own conventions for laying out dope
vectors, CHARACTER types, etc.  So in that case, too, we'd need to
have a generic interface that Fortran language support could use to
glean information from the inferior, and several ABI-specific
implementations of that interface.  We'd have files named f-abi-ffe.c,
f-abi-sun.c, or whatever.

Similar with Scheme: every Scheme implementation has its own tagging
system, and its own representations for strings, vectors, etc.  Thus,
scm-abi-guile.c, scm-abi-plt.c, etc.

Re: [RFA] Revised C++ ABI abstraction patches

[Andrew Cagney]

Jim Blandy wrote:
> 
> Eli Zaretskii <eliz@is.elta.co.il> writes:
> > >     * cp-abi-gnu-v2.c (gnu_v2_destructor_prefix_p,
> > [...]
> > >     (gnu-v3-abi.o): Add.
> > >     (gnu-v2-abi.o): Add.
> >
> > So what is it: cp-abi-gnu-v2 or gnu-v2-abi?  I prefer the latter, and I
> > thought that was the conclusion of the earlier discussions about that.
> 
> gnu-v[23]-abi were the names originally used in Daniel's patch.  I
> changed them to cp-abi-gnu-v[23], for the reasons explained in the
> ChangeLog entry provided with the patch:
> 
>         * cp-abi-gnu-v2.c, cp-abi-gnu-v3.c: Renamed from gnu-v2-abi.c
>         and gnu-v3-abi.c, to show more clearly that they are
>         implementations of cp-abi.h.
>         * Makefile.in: Adjusted accordingly.
> 
> The names `gnu-v[23]-abi' just indicate that they're implementations
> of some ABI, but the files are actually specifically dealing with C++
> ABI's.  It's not meaningful to talk about an ABI without knowing the
> source language, since an ABI is a binding between a particular source
> language and a particular machine language.

Jim, I think it is a compromize between that and the need to keep 8.3
support simple. Longer names can be introduced when GDB's directory
structure is changed.  For the moment I'd stick to something that works
on both DOS and UNIX.

This is exactly the same as what happened to:

	ui-out / mi-out, cli-out
	ui-file / mi-file, tui-file

enjoy,
	Andrew

Re: [RFA] Revised C++ ABI abstraction patches

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> Jim, I think it is a compromize between that and the need to keep 8.3
> support simple. Longer names can be introduced when GDB's directory
> structure is changed.  For the moment I'd stick to something that works
> on both DOS and UNIX.
> 
> This is exactly the same as what happened to:
> 
> 	ui-out / mi-out, cli-out
> 	ui-file / mi-file, tui-file

Okay.  Clearly this has all been discussed before --- sorry to make
everyone reiterate.

Re: [RFA] Revised C++ ABI abstraction patches

[Eli Zaretskii]

> From: Jim Blandy <jimb@zwingli.cygnus.com>
> Date: 15 Mar 2001 13:41:20 -0500
> 
> The names `gnu-v[23]-abi' just indicate that they're implementations
> of some ABI, but the files are actually specifically dealing with C++
> ABI's.  It's not meaningful to talk about an ABI without knowing the
> source language, since an ABI is a binding between a particular source
> language and a particular machine language.

The reason I wanted the previous names was that, unlike with many
other files whose names clash after truncation to 8+3, these files
will be used in building the DJGPP port.  While renaming files via
fnchange.lst might be okay for files that don't go into the build, it
is a PITA for files which do get compiled and linked, because the
Makefile's need to be edited as well.

Re: [RFA] Revised C++ ABI abstraction patches

[Jim Blandy]

Eli Zaretskii <eliz@delorie.com> writes:
> > From: Jim Blandy <jimb@zwingli.cygnus.com>
> > Date: 15 Mar 2001 13:41:20 -0500
> > 
> > The names `gnu-v[23]-abi' just indicate that they're implementations
> > of some ABI, but the files are actually specifically dealing with C++
> > ABI's.  It's not meaningful to talk about an ABI without knowing the
> > source language, since an ABI is a binding between a particular source
> > language and a particular machine language.
> 
> The reason I wanted the previous names was that, unlike with many
> other files whose names clash after truncation to 8+3, these files
> will be used in building the DJGPP port.  While renaming files via
> fnchange.lst might be okay for files that don't go into the build, it
> is a PITA for files which do get compiled and linked, because the
> Makefile's need to be edited as well.

I knuckled under, and used gnu-v[23]-abi'.  While I still don't like
the names, I didn't mean to dig up decisions people had hashed out
already.

Re: [RFA] Revised C++ ABI abstraction patches

[Eli Zaretskii]

> From: Jim Blandy <jimb@zwingli.cygnus.com>
> Date: 19 Mar 2001 12:39:27 -0500
> 
> Eli Zaretskii <eliz@delorie.com> writes:
> > > From: Jim Blandy <jimb@zwingli.cygnus.com>
> > > Date: 15 Mar 2001 13:41:20 -0500
> > > 
> > > The names `gnu-v[23]-abi' just indicate that they're implementations
> > > of some ABI, but the files are actually specifically dealing with C++
> > > ABI's.  It's not meaningful to talk about an ABI without knowing the
> > > source language, since an ABI is a binding between a particular source
> > > language and a particular machine language.
> > 
> > The reason I wanted the previous names was that, unlike with many
> > other files whose names clash after truncation to 8+3, these files
> > will be used in building the DJGPP port.  While renaming files via
> > fnchange.lst might be okay for files that don't go into the build, it
> > is a PITA for files which do get compiled and linked, because the
> > Makefile's need to be edited as well.
> 
> I knuckled under, and used gnu-v[23]-abi'.

Thanks.

Re: [RFA] Revised C++ ABI abstraction patches

[Andrew Cagney]

Jim,

When Dan originally submitted his original patch it was large. 
Fortunatly it was only (mostly) the mechanical change of separating out
the C++ stuff (it was also approved so I don't know why it wasn't
committed).  Now, however, the patch has managed to accumulate much much
more (sigh).  This really should be broken down into the mechanical
change of creating a new file and the modifications that fix real bugs.

	enjoy,
		Andrew

Re: [RFA] Revised C++ ABI abstraction patches

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> When Dan originally submitted his original patch it was large. 
> Fortunatly it was only (mostly) the mechanical change of separating out
> the C++ stuff (it was also approved so I don't know why it wasn't
> committed).  Now, however, the patch has managed to accumulate much much
> more (sigh).  This really should be broken down into the mechanical
> change of creating a new file and the modifications that fix real bugs.

I don't think this patch is really what you think it is.  Perhaps it
looks that way because of the way I wrote the ChangeLog entries.  I
was trying to preserve Dan's original log text, but I think if I just
write a log entry from scratch, it will make a lot more sense.  But do
look at the actual patch, and I think you'll see what I mean.

Oh, there is one random fix in linespec.c that should be segregated.
I'll fix that.  But folks are acting as if it's some kind of horrible
HP-style snowball, and that's not so.

Re: [RFA] Revised C++ ABI abstraction patches

[Andrew Cagney]

Jim Blandy wrote:
> 
> Andrew Cagney <ac131313@cygnus.com> writes:
> > When Dan originally submitted his original patch it was large.
> > Fortunatly it was only (mostly) the mechanical change of separating out
> > the C++ stuff (it was also approved so I don't know why it wasn't
> > committed).  Now, however, the patch has managed to accumulate much much
> > more (sigh).  This really should be broken down into the mechanical
> > change of creating a new file and the modifications that fix real bugs.
> 
> I don't think this patch is really what you think it is.  Perhaps it
> looks that way because of the way I wrote the ChangeLog entries.  I
> was trying to preserve Dan's original log text, but I think if I just
> write a log entry from scratch, it will make a lot more sense.  But do
> look at the actual patch, and I think you'll see what I mean.
> 
> Oh, there is one random fix in linespec.c that should be segregated.
> I'll fix that.  But folks are acting as if it's some kind of horrible
> HP-style snowball, and that's not so.

Ok. sorry to suggest that.

	Andrew

Re: [RFA] Revised C++ ABI abstraction patches

[Daniel Berlin]

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> Andrew Cagney <ac131313@cygnus.com> writes:
> > When Dan originally submitted his original patch it was large. 
> > Fortunatly it was only (mostly) the mechanical change of separating out
> > the C++ stuff (it was also approved so I don't know why it wasn't
> > committed).  Now, however, the patch has managed to accumulate much much
> > more (sigh).  This really should be broken down into the mechanical
> > change of creating a new file and the modifications that fix real bugs.
> 
> I don't think this patch is really what you think it is.  Perhaps it
> looks that way because of the way I wrote the ChangeLog entries.  I
> was trying to preserve Dan's original log text, but I think if I just
> write a log entry from scratch, it will make a lot more sense.  But do
> look at the actual patch, and I think you'll see what I mean.

I'll rewrite the changelog, i'm about to submit the 4th revision of
the patch, incorporating your fixes, my fixes, and my additions.


> 
> Oh, there is one random fix in linespec.c that should be segregated.
> I'll fix that.  But folks are acting as if it's some kind of horrible
> HP-style snowball, and that's not so.

It's funny, it actually removes most of the HP snowball.
--Dan

Re: [RFA] Revised C++ ABI abstraction patches

[Jim Blandy]

Daniel Berlin <dberlin@redhat.com> writes:
> I'll rewrite the changelog, i'm about to submit the 4th revision of
> the patch, incorporating your fixes, my fixes, and my additions.

Okay, sounds good.

I think I've got a decent fix for PR 34.

Re: [RFA] Revised C++ ABI abstraction patches

[Daniel Berlin]

Andrew Cagney <ac131313@cygnus.com> writes:

> Jim,
> 
> When Dan originally submitted his original patch it was large. 
> Fortunatly it was only (mostly) the mechanical change of separating out
> the C++ stuff (it was also approved so I don't know why it wasn't
> committed). 

It wasn't committed because it needed a little work.

By the time i finished the work, it had grown. Feature creep.
:(


> Now, however, the patch has managed to accumulate much much
> more (sigh).  This really should be broken down into the mechanical
> change of creating a new file and the modifications that fix real
> bugs.

Yup.

Should I break it into the addition of the new files, and the others
changes?

Unfortunately, they'll be dependent on each other, but i can't think
of how to break it up so it isn't.




> 
> 	enjoy,
> 		Andrew