Libgcc symbols

[Nix]

On 14 Apr 2001, Mark Mitchell stipulated:

OK, I've glimpsed the GCC tree up; time to use that :)

>    # ??? Some of these are for `-a', which ought to die.

(They're all, of course, basic block profiling things.)

>    __bb

This is the structure the basic block data is stored in. If -a and -ax
really are going to die, so should this.

>    __bb_exit_func

No occurrences in the GCC tree outside of libgcc2; the other
_bb_*_func's call it. If we zap __bb_init_func, __bb_fork_func and
__bb_init_trace_func and its associated static functions, we can zap
this.

It should not be exported, even if it's kept.

(It's atexit()ed; I seem to remember objections to atexit() when I tried
to use it... I guess someone was operating under the misapprehension
that something needed to be exported if it was to be atexit()ed.)

>    __bb_fork_func

Calls to this are emitted when profile_arc_flag is set, at a fork() or
exec(). It is not associated particularly with -a --- except that the
data it dumps only seems to be collected by -a. (And -ax.)

It's not clear why thsi isn't called when profile_block_flag is set,
since it doesn't seem to have anything to do with arc profiling; maybe a
typo? The arc and block stuff is all entangled in final.c, and it's all
tied up with branch probability calculation, too.

>    __bb_init_func

This seems to be purely -a related; not even -ax-related. It's called by
lots of things in config/*:

>    __bb_init_trace_func

This is called when -ax, and nowhere else.

>    __bb_trace_func

This increments the basic block counter; it's generated by
target-specific code in config/* again.

>    __bb_trace_ret

This decrements that number again, called by a lot of things in
config/*.

Only seven targets (c4x, i386, m68k, sparc, ia64, d30v, and m68ch11)
implement this function; only six targets (as above except for m64ch11)
implement the incrementor.

This does not seem to be heavily used code... can anything yet *read*
the files that -ax outputs? I cannot recall ever using it, or ever
seeing anyone use it for anything. But, equally, other than some
target-specific mess, I'm not sure how much code would actually be saved
by junking -a; it's really just writing out data that's collected anyway
for -fbranch-probabilities...

>    # ??? Symbols that perhaps unused should be nuked.
>    __builtin_saveregs

builtin_saveregs() itself just does an abort(); I think it's correct to
assume that this has been forked into target-specific versions. I can't
see why an abort() at runtime if a target-specific version is not
present is preferable to a link failure; I vote for zapping this one.

If there are any ports left that call __builtin_saveregs directly, then
they'll die whenever they call it, and the fact that nobody's reported
this in however-long is evidence that nobody has used those targets
since at least gcc-2.7.2.3 (which also has __builtin_saveregs defined
like this).

(The target-specific versions are referenced in a bunch of places, but
we're not voting on killing them...)

You could also zap an #else branch in expand_builtin_saveregs() in
builtins.c:

,----
| #else
|   /* ??? We used to try and build up a call to the out of line function,
|      guessing about what registers needed saving etc.  This became much
|      harder with __builtin_va_start, since we don't have a tree for a
|      call to __builtin_saveregs to fall back on.  There was exactly one
|      port (i860) that used this code, and I'm unconvinced it could actually
|      handle the general case.  So we no longer try to handle anything
|      weird and make the backend absorb the evil.  */
| 
|   error ("__builtin_saveregs not supported by this target");
|   val = const0_rtx;
| #endif
`----

>    __clear_cache

This is, as Jeff says, trampoline code.

It is called by INITIALIZE_TRAMPOLINE within config/arm/linux-gas.h, and
by FINALIZE_TRAMPOLINE within config/m68k/{a-ux,linux}.h, as well as by
__enable_execute_stack within libgcc2.

However, the benefits of cleaning up the libgcc2 ABI before freezing it
are such that perhaps we want to roll target-specific versions of
__clear_cache just for these two targets, and for the NeXT and Mach (for
which it is called from libgcc2), and then remove __clear_cache from
libgcc2's interface. I'm not sure.

(On the other side of the argument, this seems like a function which is
quite easy to write in a target-independent way...)

>    __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.


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.


The code itself, if it lives, needs a good flossing or a rewrite; it's a
hideous mess of target-specific #ifdefs and inline assembler :( but I
can't see a reason why it should live; it seems to be doing setup work
so that the old __builtin_saveregs could run (va_list hackwork &c), and
that is dead.


This is such a total mess I can't be sure I'm reporting
correctly. Someone else should check this, but whoever it is may need a
sick bag and some kind of bravery under fire medal afterwards.

>    __empty

This is, uh, empty. It's not used anywhere that I can see.

An aptly chosen name.

>    __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 ;)

>    __gcc_bcmp

It's in the optabs as a builtin bcmp(), unsurprisingly; it's emitted for
BLKmode comparisons on targets without an expander defined for cmpstrsi
(and for which a bunch of other conditions are true, I think indicating
signed comparison; see optabs.c:prepare_cmp_insn()).

Only three targets have a cmpstrsi pattern, so I'd guess that this code
is still quite heavily used.

(Perhaps more targets should define cmpstrsi; all that out-of-lining of
simple comparisons can't be good for speed.)

>    If these symbols appear in a released shared libgcc, we need to
>    support them as part of the libgcc ABI for ever. Thus, we must

NO! NO! NO! The thought of supporting __dummy for ever is horrible...

> He's right that we should decide about this.

I'll say.

> I don't know enough to do so.  Therefore, without further action from
> someone else, nothing will happen, and these symbols *will* be in the
> libgcc ABI.

I don't have any special knowledge either; but this is what seems to be
present in the tree right now, assuming I haven't misread anything.

> I'm going to downgrade the PR to `medium' priority, so it will go off
> my radar screen.  If anyone else cares to take more intelligent action
> here, please do so.

I hope this at least triggers some kind of discussion.

If anyone wants me to submit a patch to slaughter __dummy, I'll do so;
but I think it might be better to work out what to zap, and then zap
everything at once in one patch. (Then again, maybe not.)

-- 
`... and it's not true that I'm closely related to the three-toed
 sloth.' --- Kieran