This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Libgcc symbols
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 <assert.h> 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