Libgcc symbols

Libgcc symbols

[Mark Mitchell]

Joseph Meyers points out in PR2003 that:

  libgcc-std.ver includes:

   # ??? Some of these are for `-a', which ought to die.
   __bb
   __bb_exit_func
   __bb_fork_func
   __bb_init_func
   __bb_init_trace_func
   __bb_trace_func
   __bb_trace_ret

   # ??? Symbols that perhaps unused should be nuked.
   __builtin_saveregs
   __clear_cache
   __dummy
   __empty
   __eprintf
   __gcc_bcmp

   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
   resolve, before GCC 3.0 is released, whether each of these symbols
   should be part of the libgcc ABI or not.

He's right that we should decide about this.

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

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Libgcc symbols

[law]

  In message < 20010413211109J.mitchell@codesourcery.com >you write:
  >    # ??? Symbols that perhaps unused should be nuked.
  >    __builtin_saveregs
Some ports used to actually call __builtin_saveregs from libgcc
instead of implementing it inline.  This caused many problems over
the years and I believe the major ports have inline copies of
__builtin_saveregs.

What we need to do is determine if there are any ports left which
don't inline __builtin_saveregs and update them.


  >    __clear_cache
I'm not sure, but this might be to clear the cache to support
trampolines.  It probably needs to stay.

  >    __dummy
  >    __empty
Dunno.

  >    __eprintf
I believe this is used by GCC's assert and thus probably needs to
stay if we keep installing gcc's assert.  If we stop installing
assert.h, then we can probably zap __eprintf.


  >    __gcc_bcmp
Dunno.

jeff

Re: 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

Re: Libgcc symbols

[Zack Weinberg]

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

Re: Libgcc symbols

[Phil Edwards]

On Mon, Apr 16, 2001 at 09:08:22AM -0700, Zack Weinberg wrote:
> #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.

I don't know, but I've seen something very similar in a much less complex
project.  A static library of makeup/replacement routines was being created,
but the list of routines (and thus the list of .o files) could conceivably
be empty, causing grief for 'ar'.  A dummy .o was always created just to
ensure that 'ar' would also have at least one object file to work with.

I can't imagine all of the routines in LIB2FUNCS not being necessary,
so the __dummy here is probably for some other purpose than my example.


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

Right now, it is.  Which is a pity, because it's another layer of buffering
and function calls.  Efficiency drops considerably on some platforms when
iostreams has to funnel everything through stdio.

Ideally, we'd like the C and C++ I/O pieces to each go directly to some
common underlying layer that's as thin as possible.  When we're building on,
say, glibc 2.2 platforms, we detect that the underlying layers are already
"out there" and ignore the in-tree version.  Otherwise we build our own.

This ran into problems a while back and was disabled by default.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: Libgcc symbols

[Zack Weinberg]

On Mon, Apr 16, 2001 at 12:42:14PM -0400, Phil Edwards wrote:
> > 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.)
> 
> Right now, it is.  Which is a pity, because it's another layer of buffering
> and function calls.  Efficiency drops considerably on some platforms when
> iostreams has to funnel everything through stdio.

Then it's not thin enough to be a layer of paint, is it?

What I have in mind is a thing where

   cout << "hello world\n";

gets inline-expanded at compile time down to

   fputs("hello world\n", stdout);

and even when it can't be that simple, iostreams do no buffering at
all themselves; they leave all that to stdio.  So worst case you have
a few extra function calls.

I don't know any reason why this is not feasible, but I don't know
much about C++ at all, so there probably is a good reason why not.

zw

Re: Libgcc symbols

[Gabriel Dos Reis]

"Zack Weinberg" <zackw@Stanford.EDU> writes:

| On Mon, Apr 16, 2001 at 12:42:14PM -0400, Phil Edwards wrote:
| > > 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.)
| > 
| > Right now, it is.  Which is a pity, because it's another layer of buffering
| > and function calls.  Efficiency drops considerably on some platforms when
| > iostreams has to funnel everything through stdio.
| 
| Then it's not thin enough to be a layer of paint, is it?
| 
| What I have in mind is a thing where
| 
|    cout << "hello world\n";
| 
| gets inline-expanded at compile time down to
| 
|    fputs("hello world\n", stdout);
| 
| and even when it can't be that simple, iostreams do no buffering at
| all themselves; they leave all that to stdio.

What they actually do is controlled the underlying basic_streambuf
(given by rdbuf()).
Certainly, we need to teach the front-end to be aware of the C++
library.  But, that is a different story and hopefully one can expect
gcc-3.x (x > 0) to address those optimisation issues.  C++ makes it
possible not to sync with C I/O through sync_with_stdio() -- which can
prove to be a performance gain.

-- Gaby

Re: Libgcc symbols

[Phil Edwards]

On Mon, Apr 16, 2001 at 09:44:42AM -0700, Zack Weinberg wrote:
> > Right now, it is.  Which is a pity, because it's another layer of buffering
> > and function calls.  Efficiency drops considerably on some platforms when
> > iostreams has to funnel everything through stdio.
> 
> Then it's not thin enough to be a layer of paint, is it?

Thickness of coats of paint varies depending on the speaker.


> and even when it can't be that simple, iostreams do no buffering at
> all themselves; they leave all that to stdio.

Actually, the underlying streambuf class does all the buffering.  The streams
themselves don't, true, but there is another component which (optionally,
normally) does.

Users doing lots of I/O via standard {input,output,error} all through the
C++ facilities are encouraged to use sync_with_stdio() to turn off the
tricky sych pieces and improve performance.  And I think Benjamin just
got that working a couple weeks ago.  (Yay.)


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: Libgcc symbols

[Gabriel Dos Reis]

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

Because, we don't want to tie C++ IOstreams performance to that of C
stdio on all plateforms.  We would like to have decent I/O performance
wherever possible.  libio is one way to to do, it is certainly not the
best one; but I don't agree with implementations of C++ IOstreams on
top of C stdio.  What we have now inV3 is a short-term solution
because of some obscure implementation problems with libio.  There are
alternative schemes such as Matt Austern's implementation which worths
consideration.

-- Gaby

Re: Libgcc symbols

[Nix]

On Mon, 16 Apr 2001, Zack Weinberg yowled:
> 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.

Owch, yes. What an embarrassing mistake. However, I was using a mono
terminal over a slow link at the time, so I didn't have fontification or
anything to help.

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

That makes a *lot* of sense. If this isn't target-specific code,
*nothing* is :)

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

I fear I was unclear. I meant that the *name* has been recycled. It's
not a reference to __dummy.

> winds up defining a structure field named __dummy, which is a function
> pointer; again, no danger of clash here.

That's what I was saying :)

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

If you want to have your ears burned off, talk to Ian Jackson on the
subject. He, er, dislikes it too. Quite strongly, one might say.

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

Re: Libgcc symbols

[Richard Henderson]

On Mon, Apr 16, 2001 at 09:08:22AM -0700, Zack Weinberg wrote:
> Referenced nowhere, but I'd like to know why it was added in the first
> place before killing it.

I believe Kenner added it in the distant past as a way to reload
the PIC register after a non-local goto or exception receiver.
Which happens to work on Alpha and a few other architectures.

IIRC I removed it much later, as some architectures require the pic
register be loaded in order to perform the call in the first place,
and there are better and shorter ways to reload the PIC register
directly on the affected systems.


r~

Re: Libgcc symbols

[Joern Rennecke]

> 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?

More urgently: how do you keep crap out of the symbol map?  The
multi-precision arithmetic in libgcc.c is not much more than a proof
of concept, and results in very poor code.  Even if you need to write
an out-of-line piece of code, you can generally do much better doing so
in optimized assembler.  But the libgcc2.c versions are in the way.
For a static library, that is not an issue: you make the compiler call
a function with a different name, which is coded in lib1funcs.asm
(sometimes even with a streamlined calling convention).  The libgcc2.c
version gets still compiled to a junk .o file, but it only costs a few
bytes of disk space in the static library.
But this junk shouldn't be included in a shared library - it's just bloat.
Likewise, even where the multiprecision arithmetic is still used, this is
likely only because nobody has cared much about its performance so far.
When someone does, you want to delete that function and swap it for a
lib1funcs.asm one.  So we should only compile these functions for the
static libgcc.a (unless the target system has no concept of static
libraries).

It's much easier to add symbols than to delete them from a shared library,
so why not start with the symbols we really do want to he shared on only
put those into a shared library?

Profiling with '-a' [was Re: Libgcc symbols]

[Scott A Crosby]

On 16 Apr 2001, Nix wrote:

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

I've used basic block profiling once or twice... It can come in handy for,
for example, figuring out which way a branch tends to go in practice.

GPROF knows how to use this data (from the texinfo):

`-l'
`--line'
     The `-l' option enables line-by-line profiling, which causes
     histogram hits to be charged to individual source code lines,
     instead of functions.  If the program was compiled with
     basic-block counting enabled, this option will also identify how
     many times each line of code was executed.  While line-by-line
     profiling can help isolate where in a large function a program is
     spending its time, it also significantly increases the running
     time of `gprof', and magnifies statistical inaccuracies.  *Note
     Sampling Error::.


This annotates each basic block in the source file with a usecount.

Probably the documentation for the gcc '-a' option should be changed to
reflect this option.. People might not be using this because the gcc
manual says that the data format is unsupported by gprof.

I tested this out a year or two ago; it did work for x86. I say to not
junk it. It works, it is useful, and could be made much more useful in
terms of profile-based optimization.

May I suggest a small change to the manual, which currently reads:

       -a     Generate  extra  code  to write profile information
              for basic blocks, which will record the  number  of
              times  each  basic  block  is  executed.  This data
              could be analyzed by a program  like  tcov.   Note,
              however,  that  the  format of the data is not what
              tcov expects.  Eventually GNU gprof should  be  ex
              tended to process this data.

to something like:

Generate extra code to write profile information for basic blocks, which
will record the number of times each basic block is executed.  This data
is currently analyzed by the gprof '-l' option which will identify how
many times each line of source code is executed.  Although currently
unimplemented, eventualy GCC could be made to use this information for
profile-based optimization.

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

Whats -fbranch-probabilities? Unless it does the same as '-a', don't junk
'-a'



Scott

Re: Profiling with '-a' [was Re: Libgcc symbols]

[Nix]

On 16 Apr 2001, Scott A. Crosby said:
> I've used basic block profiling once or twice... It can come in handy for,
> for example, figuring out which way a branch tends to go in practice.
> 
> GPROF knows how to use this data (from the texinfo):

Great! Definitely don't junk it then.

I wonder whether all the extra stuff generated by -ax gets used by
anything? (I really should look rather than just asking.)

> I tested this out a year or two ago; it did work for x86. I say to not
> junk it. It works, it is useful, and could be made much more useful in
> terms of profile-based optimization.

... only -fprofile-arcs and -fbranch-probabilities already do that, more
efficiently, as it gets away without instrumenting every bb. It isn't
heavily used that I can tell; I have seen it cause ICEs here and
there. Maybe I should start doing double-bootstraps with arc data...

>                                                   Although currently
> unimplemented, eventualy GCC could be made to use this information for
> profile-based optimization.

That would be inefficient :) -fprofile-arcs already does it better, one
hopes.

> Whats -fbranch-probabilities? Unless it does the same as '-a', don't junk
> '-a'

It doesn't quite do the same. It instruments the minimum possible number
of arcs for branch probability estimation. (It's also used by test
coverage analysis.)

-fprofile-arcs and -ftest-coverage are documented in the GCC manual just
below `-ax', and -fbranch-probabilities is referenced from there.

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

Re: Libgcc symbols

[Mark Mitchell]

Thank you for the discussion.

I think that there is no question about the __builtin_saveregs that
just aborts.  We can kill that one.  However, the other version of
__builtin_savergs should stay, unless the i860 port can stop using it,
which means it need to be in the exported symbol list.

RTH, did you decide whether or not we should keep the __bb stuff?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Libgcc symbols

[Michael Meissner]

On Fri, Apr 13, 2001 at 09:11:09PM -0700, Mark Mitchell wrote:
>    # ??? Symbols that perhaps unused should be nuked.
>    __clear_cache

This is used by arm Linux, m68k Linux, and m68k a-ux to attempt to flush the
instruction cache when setting up a trampoline.

>    __eprintf

Assert macro support.

>    __gcc_bcmp

Compare strings for equality?

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: Libgcc symbols

[Joe Buck]

> >    __eprintf
> 
> Assert macro support.

__eprintf is an annoyance, frequently encountered (e.g. on Solaris) by
people who mix C code generated by gcc and by some other C compiler and
attempt to link it, thereby getting this one as an undefined symbol.

It would be nice to make it go away somehow, e.g. by relying on the vendor's
assert.h header.

Re: Libgcc symbols

[Russ Allbery]

Joe Buck <jbuck@racerx.synopsys.com> writes:

> __eprintf is an annoyance, frequently encountered (e.g. on Solaris) by
> people who mix C code generated by gcc and by some other C compiler and
> attempt to link it, thereby getting this one as an undefined symbol.

> It would be nice to make it go away somehow, e.g. by relying on the
> vendor's assert.h header.

A couple of us were discussing this elsewhere, including the fact that C99
requires that the function name also be added to the output from assert()
and most of the vendor assert.h headers probably don't do that, and I
started wondering why this was done as a libgcc library call instead of as
a statement expression.  After all, we're guaranteed that gcc's private
assert.h is always compiled by gcc.

Why not define assert as:

#define assert(expr)  \
  ((void) ((expr) ? 0 : __assert (#expr, __FILE__, __LINE__, __func__)))

#define __assert(expression, file, line, function) \
  ({                                                                    \
    fprintf (stderr, "%s:%u: failed assertion `%s' in function %s\n",   \
             expression, file, line, function);                         \
    abort ();                                                           \
  })

?  I assume that statement expressions are supposed to be allowable
anywhere that function calls are permitted.

Hurm.  I guess one problem is that this requires that one expose fprintf
and stderr somehow, probably by including stdio.h, and that violates the
C99 limits on what namespace pollution is allowed by including
assert.h....

-- 
Russ Allbery (rra@stanford.edu)             < http://www.eyrie.org/~eagle/ >

Re: Libgcc symbols

[Russ Allbery]

Russ Allbery <rra@Stanford.EDU> writes:

> Why not define assert as:

> #define assert(expr)  \
>   ((void) ((expr) ? 0 : __assert (#expr, __FILE__, __LINE__, __func__)))

> #define __assert(expression, file, line, function) \
>   ({                                                                    \
>     fprintf (stderr, "%s:%u: failed assertion `%s' in function %s\n",   \
>              expression, file, line, function);                         \
>     abort ();                                                           \
>   })

Er, with the obvious reordering of parameters to fprintf to make that
produce sensical output.  Sorry.

-- 
Russ Allbery (rra@stanford.edu)             < http://www.eyrie.org/~eagle/ >

Re: Libgcc symbols

[Richard Kenner]

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

It was used in builtin setjmp support to get GP properly restored on machines
where it was needed.  I don't see it in the current sources, so I'm curious how
this was done instead.

Re: Libgcc symbols

[Alexandre Oliva]

On Apr 16, 2001, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

> It was used in builtin setjmp support to get GP properly restored on
> machines where it was needed.  I don't see it in the current
> sources, so I'm curious how this was done instead.

builtin_setjmp_receiver

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Libgcc symbols

[Richard Kenner]

    > It was used in builtin setjmp support to get GP properly restored on
    > machines where it was needed.  I don't see it in the current
    > sources, so I'm curious how this was done instead.

    builtin_setjmp_receiver

Yes, I know that's where this sort of thing is supposed to be done, but
as far as I know, there's no way in the MIPS assembler (for O32 calling
convention) to actually *do* the GP restore.

Re: Libgcc symbols

[Alexandre Oliva]

On Apr 16, 2001, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

>> It was used in builtin setjmp support to get GP properly restored on
>> machines where it was needed.  I don't see it in the current
>> sources, so I'm curious how this was done instead.

>     builtin_setjmp_receiver

> Yes, I know that's where this sort of thing is supposed to be done, but
> as far as I know, there's no way in the MIPS assembler (for O32 calling
> convention) to actually *do* the GP restore.

Oh, I didn't realize you were talking specifically about MIPS.  I
suppose GP may have to be stored in the stack frame somewhere, by
builtin_setjmp_setup or the function prologue, so that
builtin_setjmp_receiver can restore it.  But then, I know very little
of MIPS calling conventions, so there may even be a reason why this
would be impossible to do.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Libgcc symbols

[Richard Henderson]

On Mon, Apr 16, 2001 at 03:27:52PM -0400, Richard Kenner wrote:
> Yes, I know that's where this sort of thing is supposed to be done, but
> as far as I know, there's no way in the MIPS assembler (for O32 calling
> convention) to actually *do* the GP restore.

Nope, there isn't.  Not relying on the magic store that it
emits in the prologue anyway.

So instead we drop the GP value into the builtin jmpbuf and
have builtin_longjmp restore it directly.


r~

Re: Libgcc symbols

[Richard Kenner]

    Oh, I didn't realize you were talking specifically about MIPS.  I
    suppose GP may have to be stored in the stack frame somewhere, by
    builtin_setjmp_setup or the function prologue, so that
    builtin_setjmp_receiver can restore it.  But then, I know very little
    of MIPS calling conventions, so there may even be a reason why this
    would be impossible to do.

At the time I added _dummy, I was told it could not be done, but I forget
exactly why.  The suggestion was to pass the address of a function and call
it since the return from that call would set GP.

Re: Libgcc symbols

[dewar]

<<Oh, I didn't realize you were talking specifically about MIPS.  I
suppose GP may have to be stored in the stack frame somewhere, by
builtin_setjmp_setup or the function prologue, so that
builtin_setjmp_receiver can restore it.  But then, I know very little
of MIPS calling conventions, so there may even be a reason why this
would be impossible to do.
>>

My understanding is that it is the MIPS assembler that takes charge of
GP restore, so you really do need to generate a dummy call to get GP
restored properly.

Re: Libgcc symbols

[Richard Kenner]

    I believe Kenner added it in the distant past as a way to reload
    the PIC register after a non-local goto or exception receiver.
    Which happens to work on Alpha and a few other architectures.

No, Alpha was fine.  It was SGI IRIX O32 where you need to make the
call to restore GP.

Re: Libgcc symbols

[dewar]

<<So instead we drop the GP value into the builtin jmpbuf and
have builtin_longjmp restore it directly.
>>

OK, in our original design we were intent on absolutely minimizing the
setjmp time, so that is why we preferred to have the assembler reload
the GP on the longjmp (also it kept things more target independent).
But, indeed it works fine to include GP in the jmpbuf.