From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zack Weinberg" To: Nix Cc: gcc@gcc.gnu.org Subject: Re: Libgcc symbols Date: Mon, 16 Apr 2001 09:08:00 -0000 Message-id: <20010416090821.L339@stanford.edu> References: <20010413211109J.mitchell@codesourcery.com> <87bspxkqgk.fsf@loki.wkstn.nix> X-SW-Source: 2001-04/msg00708.html On Mon, Apr 16, 2001 at 12:56:59PM +0100, Nix wrote: > > __dummy > > This one *must* be dead. It is referenced nowhere in the tree, and it > calls __builtin_saveregs by name --- not the target-specific > version. Anyone that did *that* in the last few years would have > aborted. This should die. I think you've mixed up __dummy with the code immediately following it. #ifdef L__dummy void __dummy (void) {} #endif Referenced nowhere, but I'd like to know why it was added in the first place before killing it. The code immediately following is indeed a horrid mess, but its control macro is L_varargs, and it *defines* a nontrivial __builtin_saveregs for, um, three different architectures: mips, sparc, and i860. The mips and sparc ports appear not to use it anymore. i860 does (i860.c:i860_saveregs, called via EXPAND_BUILTIN_SAVEREGS). It shouldn't be _that_ hard to change i860_saveregs to emit in-line code the same way all the others do, and then this can disappear. Or the logic could be moved to config/i860/lib1funcs.asm. This does raise a question in my mind: if a target defines additional support routines in a lib1funcs.asm, how do they get into the symbol map? > The name has been recycled in libstdc++-v3, but only the name; it > shouldn't generate external references. (Of course, one typo and it > *will*, and all hell may break loose. I doubt that though.) > > It's also been recycled by libio, wrapped in a mess of macros to confuse > people into thinking that this is a reference to the function. Gaah. Appears to be used only as a template parameter or variable name, so should be harmless. Libio's a fetid pile of dingo entrails, but I am fairly sure that struct _IO_jump_t { JUMP_FIELD(_G_size_t, __dummy); winds up defining a structure field named __dummy, which is a function pointer; again, no danger of clash here. Why we still have libio in-tree at all is another question. (I have never understood why iostreams aren't a layer of paint on top of the public stdio interface.) > > __eprintf > > Assertion printing, as Jeff says. I think it needs to stay; but the > direct call to it in testsuite/gcc.dg/noncompile/920923-1.c should > perhaps go, if anyone can work out what on earth that testcase is > testing ;) Someone pointed out about a year ago that we really shouldn't be overriding the system on almost every target. The only targets that presently get to use their assert.h are interix, beos, mcore (whatever that is), linux, netbsd, openbsd, and rtems. assert.h didn't (to my knowledge) exist at all before C89; it'd probably be safe to assume that if /usr/include/assert.h exists, we don't need to touch it. We're stuck with __eprintf or equivalent on older targets, but they won't be using shared libgcc, so it's not an issue. It might make sense to change it to be SVID's __assert instead; assertions take less space with that interface. In any case, leaving __eprintf in the public libgcc2 ABI is harmless. It's not like it needs hacking up on a regular basis :) zw