Re: [PATCH 18/29] tools/xenstored: rename xenbus_evtchn()

[Julien Grall <julien@xxxxxxx>]

Hi Juergen,

On 01/11/2023 11:08, Juergen Gross wrote:
> On 01.11.23 11:44, Julien Grall wrote:
> > Hi Juergen,
> >
> > On 01/11/2023 09:33, Juergen Gross wrote:
> > > Rename the xenbus_evtchn() function to get_xenbus_evtchn() in order to
> > > avoid two externally visible symbols with the same name when Xenstore-
> > > stubdom is being built with a Mini-OS with CONFIG_XENBUS set.
> > This works right now, but what guarantee us that Mini-OS will not 
> > change other symbols and clash with the one provided by Xenstored again?
> > Furthermore, technically, this is a problem for all the other software 
> > linked with Mini-OS. So wouldn't it be better to modify the Mini-OS 
> > build system to prefix all the symbols of the linked binary (here 
> > Xenstored)?
> How would that work?
>
>  From Mini-OS point of view libraries are not distinguishable from the
> linked application. This would mean the build system would prefix the
> library symbols as well, while the application would try to reference
> the the un-prefixed library symbols.
AFAICT, objcopy could rename symbols. So if you pre-process the 
libraries and application before hand, then you should still be able to 
link.
> I think the only way to avoid this kind of problem would be to have a
> positive list of exported Mini-OS symbols and to hide all other symbols
> from linked libraries and the app.
>
> I can look into this, but I'd like to do this work outside of this
> series in order not to block its development for an unknown amount of
> time.
I am ok with that:

Reviewed-by: Julien Grall <jgrall@xxxxxxxxxx>

Cheers,

--
Julien Grall