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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
