<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 8, 2020 at 10:30 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 08/04/2020 17:57, Jonathan Brandmeyer wrote:<br>
<br>
> There are a couple more disadvantages.<br>
><br>
> Which definition is pulled into the final link depends on the order <br>
> that the object files are listed on the command-line.  If the weak one <br>
> is seen first, then the linker will resolve the symbol against the <br>
> weak definition and it won't even search into subsequent archives for <br>
> the strong one.  It will merely suppress multiple-definition errors at <br>
> link time.<br>
><br>
> We ran into this issue in our project when we over-rode some RTEMS <br>
> weak symbols in one of our static archives.  Since the dependency <br>
> graph seen by the linker was from one object in librtems.a to another <br>
> object in librtems.a, the only way we could reliably pull in our <br>
> override was by listing our archive as an object to be linked instead <br>
> of as an archive to be searched (ie, named as libour_runtime.a instead <br>
> of -lour_runtime on the link step command).<br>
<br>
For the linker weak functions are like ordinary functions during the <br>
symbol resolving phase. If the linker finds the weak one first, then it <br>
is happy and stops searching.</blockquote><div><br></div><div>Correct, that's why it behaves this way.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If you encounter problems like this, then <br>
weak functions are used for the wrong thing.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I would like to use weak functions with one level of indirection. For <br>
example an application can use two features A and B. Both use an <br>
interface C. If only A is used, then C can be implemented via D or E. If <br>
B is used, then C must be implemented via E. For this you can use a weak <br>
implementation D of interface C in module of A and a strong <br>
implementation E in module of B.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>It's pretty easy to provide a definition of Init() or POSIX_Init() that doesn't directly call malloc or free, for example.</div><div><br></div><div>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.</div></div><div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Jonathan Brandmeyer<br>PlanetiQ</div></div>