Re: Libgcc symbols

[Nix <nix@esperi.demon.co.uk>]

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