Use weak functions in the RTEMS core?

[Sebastian Huber]

On 08/04/2020 19:34, Jonathan Brandmeyer wrote:
>
>     If you encounter problems like this, then
>     weak functions are used for the wrong thing.
>
>
> Exhibit A: zynq_setup_mmu_and_cache.  It is referred to only by the 
> BSP's startup sequence.  So it is a reference from librtemsbsp to 
> librtemsbsp by default.  I don't think it's being used for the wrong 
> thing.
You could move zynq_setup_mmu_and_cache() to a separate file and remove 
the weak. The weak function here just avoids an extra file.
>
>
>     I would like to use weak functions with one level of indirection. For
>     example an application can use two features A and B. Both use an
>     interface C. If only A is used, then C can be implemented via D or
>     E. If
>     B is used, then C must be implemented via E. For this you can use
>     a weak
>     implementation D of interface C in module of A and a strong
>     implementation E in module of B.
>
>
> In the proposed case of using weak references for the heap, which 
> implementation gets pulled in depends on whether or not the object 
> files listed on the command line reference the heap or not.  If the 
> only references are within static archives, then the application will 
> have difficulty choosing exactly which implementation of the heap gets 
> pulled in.  librtemsbsp both depends-on and provides implementations 
> of malloc and free.
>
> It's pretty easy to provide a definition of Init() or POSIX_Init() 
> that doesn't directly call malloc or free, for example.

In my proposed use case:

We could use something like this in heapallocate.c:

RTEMS_WEAK void *_Heap_Allocate_impl(size) { /* Very simple */ }

void *_Heap_Allocate(size)

{

   return _Heap_Allocate_impl(size)

}

In heapfree.c:

void *_Heap_Allocate_impl(size) { /* Complex */ }

The application doesn't reference _Heap_Allocate_impl(). It references 
_Heap_Allocate() or _Heap_Free() or both or none.

>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200408/f0f5ac06/attachment.html>