[Top][All Lists]

[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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]