[no subject]

- export as little as possible.  References to objects not exported are
  relative and don't require name lookup.

  As a consequence this means use callbacks whenever possible.  Instead
  of exporting a 10 functions export only one function which fills in a
  data structure with information about those 10 functions so that they
  can be called indirectly.  And before you say indirect calls suck
  remember that calls via the PLT etc are also relative.  So there is no
  penalty added.

- never export variables.  Always functions which return pointers to
  variables.

- made easy by the first point above: explicitly use dlopen() to load
  DSO.  This is lazy loading implemented correctly.  The application
  controls when another DSO is needed.  By using callbacks the amount
  of work needed to use the newly loaded DSO is minimal: just call the
  function to get the callbacks.  Note how easy it is to just fill in
  the callback structure with pointers to functions which load the DSO
  if necessary.

- don't load DSOs with RTLD_GLOBAL.  This is a performance killer since
  the global name space is extended.  Before any symbol is found in
  those newly loaded DSOs all other DSOs and the main application are
  searched.

- in a DSO, call functions which are exported but which you don't want
  to be interposed with an alias.  This is most probably a good idea
  in all situations but might introduce problems if this change is
  introduced after the DSO is already started being used.  Nevertheless,
  is justified.

  To see what can be done look at the .rel.plt/.rela.plt section in
  your DSO.  Ideally it should be empty/non-existing.

- while we are at it, look at the other relocations.  All relocations
  should be relative relocations unless you explicitly reference code
  somewhere else.

- don't rely on interposition, not explicitly in code nor using
  LD_PRELOAD.  This will kill a lot of the possible optimizations.  If
  you have to enhance an interface create a new one, don't overload
  the name.

- put functions as much as it makes sense in separate source files.
  Some code simply belongs together and a function of the group isn't
  called alone.  That's fine.  But if there are programs using one
  subset of the functions but none of the remaining functions the
  sources should reflect that.  Ideally tools should be available to
  figure this out but these tools must use heuristics and these will
  definitely fail on occasion.  Everything the programmer is
  implementing explicitly cannot be handled incorrectly by the tool.

- not to be mentioned, of course, is the fact that every DSO with text
  relocations must be changed.  Often this only requires correct
  recompilation but sometimes it's invalid code (mostly assembler)
  which needs to be rewritten.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers