[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnucap-devel] dispatcher and link order
From: |
Felix Salfelder |
Subject: |
[Gnucap-devel] dispatcher and link order |
Date: |
Sun, 30 Jun 2019 18:26:06 +0200 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
Hi Al.
I have had another look at the pending dispatcher rework which was meant
to provide dynamically allocated dispatchers.
There is some overlap with randomised static construction order
mitigation. As Christian pointed out correctly, we should not rely on
the construction order, as more linkers tend to behave randomly.
The rework had introduced a tweak that created the _map instance on
demand. the intent was to defer the crash, while printing the link order
warning. The crash was then caused during shutdown, because the map was
deleted before all content was uninstalled.
There are two ways around it.
1 don't delete _map (in static instances). _map will be deleted anyway,
so there is no difference in production builds.
But in a debugging build, we also check if all contents are
gone, before deleting _map. This will now lead to false positives, if
the link order is wrong.
2 make sure objects are installed after dispatcher creation. This would
basically mean that the library needs to be split. globals would have
to become part of main, or the "internal" plugins would have to become
loaded like the default plugins.
I dislike 2, hence I implemented 1 (see link_order branch). Please have
a look if this is good enough for develop.
NB: the reason we postponed the dynamic dispatchers was the interface
incompatibility. this can be easily avoided by just using the old
dispatcher header (on an unaffected platform).
cheers
felix
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnucap-devel] dispatcher and link order,
Felix Salfelder <=