Re: link order

On Sat, Jun 29, 2019 at 10:10:24PM +1200, Christian Gagneraud wrote:
> But yes, every now and then this can happen. because _map is not initialised.

You are reiterating that, at the start of the program, _map is not zero
in static instances. is there any evidence for this? any ref to a
standard?

it was like that in ANSI-C, and, to my knowledge, nothing ever changed.

> I once had to maintain a code base with such a 'static plugin system'.
> It worked well for ages, and one day I had to manage 2 version of an
> arm-linux-gcc toolchain (from different vendors).
> 
> One of the toolchain would provoke early crashes.
> The fix was to reverse the link order of the executable, this was a
> makefile based project, and i had a special rule that depended of the
> version of gcc, to handle the link order.

reversing the link order is a trivial change, that we could easily do
(even conditionally, depending on the tool chain).

you claim that dispatchers cannot work in principle, which i am hesitant
to believe. i think we need to disentangle more carefully into

- what is static memory initialised to (and why do you think it is not
  zero)?
- how can we control the link order (i.e. the order of static instances)
  better?
- how can we deal with error cases (i.e. if the linker or user got it
  wrong)?
- what compilers actually do misbehave and in which way, regardless of
  what the standard says.

clearly, if we managed to control the link order, we wouldn't have to
rely on the zero initialisation, which is (only) used in the
troubleshooting code.  we simply can't get rid of it without anything
better in place.

please let us know if you have a workable solution for this, or even an
alternative approach that achieves the goal.

thanks
felix

PS: please Patrick, give us more details on the error you are actually
seeing -- this is getting a bit theoretical (:

_______________________________________________
Gnucap-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnucap-devel