[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] link order
From: |
Felix Salfelder |
Subject: |
Re: [Gnucap-devel] link order |
Date: |
Sat, 29 Jun 2019 12:41:24 +0200 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
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] gnucap build with CMake on Windows, Patrick Mulder, 2019/06/28
- Re: [Gnucap-devel] gnucap build with CMake on Windows, Patrick Mulder, 2019/06/28
- Re: [Gnucap-devel] gnucap build with CMake on Windows, Felix Salfelder, 2019/06/28
- Re: [Gnucap-devel] gnucap build with CMake on Windows, Christian Gagneraud, 2019/06/28
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29
- Re: [Gnucap-devel] link order, Christian Gagneraud, 2019/06/29
- Re: [Gnucap-devel] link order,
Felix Salfelder <=
- Re: [Gnucap-devel] link order, Christian Gagneraud, 2019/06/29
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29
- Message not available
- Re: [Gnucap-devel] link order, Patrick Mulder, 2019/06/29
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29
- Message not available
- Message not available
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/30
- Message not available
- Message not available
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/30
- Message not available
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29