[Bug libobjc/48177] incorrect registration of typed selectors

["nicola at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48177

Nicola Pero <nicola at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.03.18 15:22:25
     Ever Confirmed|0                           |1

--- Comment #3 from Nicola Pero <nicola at gcc dot gnu.org> 2011-03-18 15:22:25 UTC ---

> The problem showed up with argframe information in base ... which presumably
> means that something in base is getting that wrong :-(

Ok - I see.  So, something in base is trying to create a typed selector at
runtime, and register it.  The argframe information in the generated types
doesn't  match the existing one (probably because they are generated buggy,
it's hard to generate them reliably), and the selector gets registered again.

If we were using sel_types_match(), then gnustep-base wouldn't need to provide
argframe information at all, assuming a selector with the same type already 
exists ?  Or if it provides a buggy one, it would be discarded in favour of the
existing one ?

Assuming that most compiler-generated typed selectors (which include valid
type information) are loaded in the runtime before any selector generated
by gnustep-base (or anything else) on the fly at runtime (which may include 
buggy types), then this should generally work in making sure the correct
types are used. :-)

So, I guess we should do it as it should get things to work generally better.

Is this a critical bug ?  Ie, would it actually cause any visible trouble
to users (as opposed to some inefficiency) ?  If so, we need a testcase so
we can backport it at some point to 4.6.x.


> I wonder, could we have a runtime function to take a type encoding without
> argframe info, and convert it to one with argframe info using the same
> algorithm the compiler uses?

If we could do that, then we would not need the argframe info in the selectors
at all. ;-)

In fact, maybe we should get rid of it, or hide it "more" inside the runtime.

It would be nice to audit exactly when and how it is used, and what the 
relationships are between the various parts.  Ideally we'd get rid of the
need for gnustep-base or even end-users to see or know about the argframe
layout information.  Let's have a chat about that offline.

Thanks