On Mon, Apr 13, 2020 at 11:48 PM Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
>
> On 09/04/2020 17:25, Gedare Bloom wrote:
>
> > On Wed, Apr 8, 2020 at 10:53 PM Sebastian Huber
> > <sebastian.hu...@embedded-brains.de> wrote:
> >> On 09/04/2020 03:32, Chris Johns wrote:
> >>
> >>> On 2020-04-09 03:43, Sebastian Huber wrote:
> >>>> On 08/04/2020 19:34, Jonathan Brandmeyer wrote:
> >>>>> Instead of treating weak references as a single level of
> >>>>> indirection, I think you have to treat them as a single overridable
> >>>>> interface. In a dynamically-linked application, we might try to
> >>>>> perform an override using the LD_PRELOAD feature. But in a
> >>>>> statically-linked application we have to do it differently. The
> >>>>> overriding archive must be named in full, and it must be named as an
> >>>>> object to be linked instead of a library to be searched.
> >>>>> Furthermore, an interface can have only one override that ends up in
> >>>>> the linked application.
> >>>> Yes, you can only have one strong implementation, otherwise you get
> >>>> multiple definition errors.
> >>> I have only ever considered weak references as an overridable
> >>> interface within a user's application and not layered within RTEMS
> >>> itself. I am not sure about automatic indirection within an archive.
> >> Yes, this is one use case. You could use also a normal function in a
> >> separate file to get something similar.
> >>> In the case of different heap allocators why not have confdefs.h
> >>> select the one we want and manage the indirection with a const table
> >>> of pointers?
> >> Yes it can be done with new configuration options, however, this would
> >> be my least favorite choice. I created an example how I would like to
> >> use weak functions:
> >>
> >> https://lists.rtems.org/pipermail/devel/2020-April/059196.html
> >>
> > Thanks for the code example it was helpful to me. What I understood is that:
> > 1) An internal interface may be declared weakly aliased in RTEMS.
> Yes, in this example and the other things I have in mind with weak
> functions, the weak function implements an internal interface.
> > 2) Implementations each need to go to a different file.
> > * Not clear to me if there can be more than 2: 1 weak, 1 strong?
> Exactly one strong implementation in librtemscpu.a and at least one weak
> implementation. If you have multiple weak implementations and no strong
> one is referenced, then the first weak implementation seen by the linker
> wins.
> > 3) A strong implementation may be pulled in by invoking a different,
> > non-aliased function implemented in the same file as (one of) the
> > strong implementations.
> Yes. In the example, the application references free() and this enables
> the full support for the deferred free.
> >
> > Am I understanding this? I tried to map this to something in OOP but
> > the abstraction failed somewhere in my cortex. It is almost like an
> > interface class where you can instantiate objects of only one of the
> > implementations.
> >
> > The weakly aliased interface proposal under consideration is NOT a
> > public API, at least so far. It is not yet clear to me how or whether
> > the approach can be used in conjunction with a weak public interface.
> I don't know a mapping to OOP. The weak functions are a bit special.
> >
> > I am a little concerned that the approach is fragile still, based on
> > the discussion about how weak aliases may be resolved dependent upon
> > link order in command lines, etc.
>
> The dose makes the poison. This stuff should be used with care and a
> clear purpose. The example with the deferred free doesn't depend on a
> link order.
>
> For me the question is if we want to use a feature which depends on the
> ELF format. I would say yes, since even if a future format doesn't
> support weak functions, then we can still use workaround based on global
> pointers and system initialization handlers.
>
I'm leaning in favor of this proposal for some very clear use cases.
It is an elegant way to handle the problem of customizable
implementations to specialize some features. Maybe let's try out the
approach with the heap management in rtems6 without modifying the user
APIs.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
