Dump sizes of objects in the .

* bin/relocstat: dump sizes of objects in the .data section,
interesting indeed:
* doc/link-relocs.txt: more random thoughts.

1 files changed, 238 insertions, 0 deletions

diff --git a/doc/link-relocs.txt b/doc/link-relocs.txt
new file mode 100644
index 000000000..8a8507eb6
--- /dev/null
+++ b/doc/link-relocs.txt
@@ -0,0 +1,238 @@
+Relocations:
+
+** Interesting questions
+    + we do 1 relocation, per virtual method, per class/sub-class
+	+ ... fun ...
+    + do we do -lots- of relocations for 'weak' / vtables that we
+      can *know* will not be used ever (?)
+	+ COMDAT support should eliminate them anyay (?)
+	+ how many relocations take place inside (weak) objects ?
+	+ what is the average size of a weak object ...
+        + eg. the _ZTV15SvxCheckListBox is only defined in 1 place
+	  ie. we prolly don't have tons of duplicate/redundant
+	  vtables inc. relocations. vtable emitted as 1st virtual is
+	  defined (?).
+
+    + I remember [!] - the reason why we analyse only .rel.dyn
+	+ it is processed immediately
+	      + .rel.plt is lazily processed ...
+
+    + interesting KDE related paper:
+	+ http://www.suse.de/~bastian/Export/linking.txt
+		+ everything called 'kdeinit' - linked & then forks
+		  => still relocated etc. => upgrade libraries & no
+		     change until kdeinit is restarted
+		+ ... interesting solution ...
+	+ speculation from related thread:
+	
+	    + by Johannes Sixt on Wednesday 09/May/2001, @02:35
+
+	      AFAIK, Windows DLLs have a "preferred address". If the
+	      dynamic linker finds that the preferred address is
+	      unallocated and there's enough room to take up the DLL
+	      at that address, it is loaded there, and no relocation
+	      is needed. Otherwise, it loads the DLL at a different
+	      address and relocates it.
+
+	      I think that this is the best thing to do: When a
+	      library is linked, it has to be decided in some way what
+	      the preferred address is. This must take into account
+	      the shared objects that the library depends on.  [ Reply
+	      To This | View ]
+
+	      + Re: An Analysis of KDE Speed
+	      + by Erik Hensema on Wednesday 09/May/2001, @05:13
+
+	        DLLs do have a preferred address. However, as soon as
+	        a DLL has to be relocated, it can't be shared anymore,
+	        because windows has no concept of Posistion
+	        Independent Code (PIC): all function calls inside the
+	        DLL have to be changed when it is relocated.
+
+		Linux (and all other Unices I know of) does support
+		PIC: it is essential to the ELF binary format,
+		AFAIK. This means relocation isn't expensive: the
+		pages of the libary won't have to be touched, making
+		them shareable.
+
+		The thing both the Windows and Unix dynlinkers have to
+		do is to resolve the calls made by an application to a
+		library (or lib -> lib): the app makes a call to a
+		fixed address, inside the relocation table. The
+		dynlinker generates a call on this fixed address to
+		the dynamically linked function.
+
+		The problem with KDE is the sheer number of function
+		calls exposes the inefficiency of the dynlinker.
+
+		Loading a library on a preferred address may speed up
+		this proces. It may break ELF though.
+
+    + Possible approaches:
+	+ prelink
+	    + similar to SGI's IRIX 'rebase' tool
+	    + very fast, very ugly - slows system updates
+	    + works for C, C++, system startup etc.
+	+ shmem handshake with 'link-daemon': do the dlink in
+	  another process via shared memory. - ie. system-wide
+	  pre-linking / caching...
+	    + all but 1st time very fast - demand built cache
+	    + 1st time somewhat slower - to reduce handshaking
+	      would want to do LD_BIND_NOW or equiv.
+	    + works for C, C++, system startup etc.
+	+ re-work gcc to ensure 
+	+ add link hooks for 'idle-linkage' slots (?)
+	    + can we get virtual methods into the plt ?
+	    + instead of a vtable: a 'code-table'
+		+ ie. jump edx + <shim-size>*foo
+		+ that shim would be ? a ton of plt references ...
+		+ ie. jump into the vtable itself - rather than 
+		  the code
+		    => bloat ? what is the size of a PLT entry ?
+		+ [ compatibility ]:
+		    + can keep the existing code & absolute offset ? -
+		      have a non-symbol-driven pathetic relocation,
+		      pointing to the end of the vtable ?
+		    + at the end => no vicious vtable offset
+		      calculation problems (?!)
+	    + works only for C++
+	    * elaboration *
+		+ a re-linker that would add these slots post-compile
+	+ fix g++/binutils to add 'export' (ie. -Bsymbolic) style
+	  markup to all (non-weak?) symbols exported from a visibility
+	  annotated class.
+	    + partial solution - normally kills < 50% of the relocs
+	    + works only for C++
+	+ a new / PLT-like approach
+	    + we do *maths* to calculate the offset into the vtable
+	      anyway - before a virtual call, surely that logic must
+	      consume a register or two we can rely on (?)
+	    + can we not call a shim / dlink helper instead
+		+ classes can have a table of PLT-like slots chained
+		  from the vtable to build the table with.
+		+ (or a single, initial relocation per vtable)
+		+ => can relocate lazily ...
+	    + ... PLT entry into the vtable ...
+
+
+
+    + Tool to dump '.data' and '.got' sections (?)
+	+ and unwind which relocations are in which symbols/elements
+	  there precisely....
+	+ tool to calculate how many vtables, their size, average
+	  number of slots etc.
+	
+    + work out how large a plt entry is & how many vtable
+      entries we have.
+
+
+
+    + analysing libsvx:
+	+ objdump -R libsvx680li.so | grep -v '\*ABS\*' \
+	          | cut -c 28-100 | sort | uniq -c | sort -n
+    + result:
+	+ 17k unique symbol 
+
+    + questions:
+	+ what are these symbols ?
+	    + internal vs. external
+	    + weak vs. strong
+	    + & a better understanding of why we need
+	      so - so many relocs.
+
+    + Analysis of internal{weak/strong}/external gives:(relocstat)
+	+ libsvx680li.so total relocs 17483 external 5204, internal weak 2888, internal strong 9391: saving 54%
+
+    + KDE has a -far- smaller relocation count: why ? - deep/virtual trees ?
+
++ Random analysis of 20 relocs:
+
+SvxRTFParser::CalcValue()	_ZN12SvxRTFParser9CalcValueEv
+	+ svx/inc/svxrtf.hxx:
+	    + virtual void CalcValue() - an internally resolvable / global symbol
+		+ cost: 1 symbol, 1 relocation, etc.
+
+SvTreeListBox::MakeVisible(SvLBoxEntry*)	_ZN13SvTreeListBox11MakeVisibleEP11SvLBoxEntry
+    + checklbx.hxx:class SVX_DLLPUBLIC SvxCheckListBox : public SvTreeListBox
+autocdlg.o
+000000e0 R_386_32          _ZN13SvTreeListBox11MakeVisibleEP11SvLBoxEntry
+cfg.o
+000000e0 R_386_32          _ZN13SvTreeListBox11MakeVisibleEP11SvLBoxEntry
+000000e0 R_386_32          _ZN13SvTreeListBox11MakeVisibleEP11SvLBoxEntry
+    + ** fascinating ** - to see the vtable laid out, in all it's glory:
+eg.
+        .hidden _ZTV14MenuSaveInData
+        .weak   _ZTV14MenuSaveInData
+        .section        .gnu.linkonce.d._ZTV14MenuSaveInData,"awG",@progbits,_ZTV14MenuSaveInData,comdat
+        .align 32
+        .type   _ZTV14MenuSaveInData, @object
+        .size   _ZTV14MenuSaveInData, 36
+_ZTV14MenuSaveInData:
+        .long   0
+        .long   _ZTI14MenuSaveInData
+        .long   _ZN10SaveInData8GetImageERKN3rtl8OUStringE
+        .long   _ZN14MenuSaveInData6HasURLERKN3rtl8OUStringE
+        .long   _ZN14MenuSaveInData11HasSettingsEv
+        .long   _ZN14MenuSaveInData10GetEntriesEv
+        .long   _ZN14MenuSaveInData10SetEntriesEPN4_STL6vectorIP14SvxConfigEntryNS0_9allocatorIS3_EEEE
+        .long   _ZN14MenuSaveInData5ResetEv
+        .long   _ZN14MenuSaveInData5ApplyEv
+
+checklbx.o
+000000e0 R_386_32          _ZN13SvTreeListBox11MakeVisibleEP11SvLBoxEntry
+    + implements SvxCheckListBox
+	+ inherits from SvTreeListBox
+	+ which implements:
+		virtual void	MakeVisible( SvLBoxEntry* );
+... tons of other SvxCheckListBox relocations ...
+        .weak   _ZTV15SvxCheckListBox
+        .section        .gnu.linkonce.d._ZTV15SvxCheckListBox,"awG",@progbits,_ZTV15SvxCheckListBox,comdat
+        .align 32
+        .type   _ZTV15SvxCheckListBox, @object
+        .size   _ZTV15SvxCheckListBox, 540
+    _ZTV15SvxCheckListBox:
+        .long   0
+        .long   _ZTI15SvxCheckListBox
+        .long   _ZN15SvxCheckListBoxD1Ev
+        .long   _ZN15SvxCheckListBoxD0Ev
+        .long   _ZN13SvTreeListBox9MouseMoveERK10MouseEvent
+        .long   _ZN15SvxCheckListBox15MouseButtonDownERK10MouseEvent
+	...
+        .long   _ZN13SvTreeListBox11MakeVisibleEP11SvLBoxEntry
+
+
+
+non-virtual thunk to E3dView::~E3dView()        _ZThn16_N7E3dViewD1Ev
+svt::EditBrowseBox::ResizeController(svt::CellControllerRef&, Rectangle const&) _ZN3svt13EditBrowseBox16ResizeControllerERNS_17CellControllerRefERK9Rectangle
+non-virtual thunk to FmXGridPeer::disposing(com::sun::star::lang::EventObject const&)   _ZThn384_N11FmXGridPeer9disposingERKN3com3sun4star4lang11EventObjectE
+SvxCaseMapItem::Store(SvStream&, unsigned short) const  _ZNK14SvxCaseMapItem5StoreER8SvStreamt
+non-virtual thunk to SvxUnoText::~SvxUnoText()  _ZThn76_N10SvxUnoTextD0Ev
+non-virtual thunk to accessibility::AccessibleShape::queryInterface(com::sun::star::uno::Type const&)   _ZThn36_N13accessibility15AccessibleShape14queryInterfaceERKN3com3sun4star3uno4TypeE
+SdrModel::SetReadOnly(int)      _ZN8SdrModel11SetReadOnlyEi
+SdrObject::NbcSetLogicRect(Rectangle const&)    _ZN9SdrObject15NbcSetLogicRectERK9Rectangle
+Edit::LoseFocus()       _ZN4Edit9LoseFocusEv
+typeinfo for sdr::contact::ViewContact  _ZTIN3sdr7contact11ViewContactE
+non-virtual thunk to accessibility::AccessibleShape::queryInterface(com::sun::star::uno::Type const&)   _ZThn44_N13accessibility15AccessibleShape14queryInterfaceERKN3com3sun4star3uno4TypeE
+svx::FormatPaintBrushToolBoxControl::Select(unsigned char)      _ZN3svx30FormatPaintBrushToolBoxControl6SelectEh
+SvxUnoTextRangeBase::compareRegionStarts(com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&, com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&)  _ZN19SvxUnoTextRangeBase19compareRegionStartsERKN3com3sun4star3uno9ReferenceINS2_4text10XTextRangeEEES9_
+SdrCircObj::CheckHit(Point const&, unsigned short, SetOfByte const*) const      _ZNK10SdrCircObj8CheckHitERK5PointtPK9SetOfByte
+SvxRTFParser::UnknownAttrToken(int, SfxItemSet*)        _ZN12SvxRTFParser16UnknownAttrTokenEiP10SfxItemSet
+non-virtual thunk to SvxShape::removePropertiesChangeListener(com::sun::star::uno::Reference<com::sun::star::beans::XPropertiesChangeListener> const&)      _ZThn40_N8SvxShape30removePropertiesChangeListenerERKN3com3sun4star3uno9ReferenceINS2_5beans25XPropertiesChangeListenerEEE
+typeinfo for SvxFontMenuControl _ZTI18SvxFontMenuControl
+SvxShadowItem::HasMetrics() const       _ZNK13SvxShadowItem10HasMetricsEv
+non-virtual thunk to SvxFmDrawPage::~SvxFmDrawPage()    _ZThn48_N13SvxFmDrawPageD1Ev
+typeinfo for XLineDashItem      _ZTI13XLineDashItem
+
+
++ Random selection of high hit-count symbols 8 or more (1170) ...
+      8 _ZThn172_N12SvxShapeText14queryInterfaceERKN3com3sun4star3uno4TypeE
+     54 _ZThn20_N17SfxToolBoxControl14queryInterfaceERKN3com3sun4star3uno4TypeE
+    199 _ZN6Window8ActivateEv
+     11 _ZN9E3dObject10NbcRotateZEd
+      9 _ZN18TransferableHelper8dragOverERKN3com3sun4star12datatransfer3dnd19Drag
+     14 _ZN9SdrObject9NbcMirrorERK5PointS2_
+     11 _ZNK13SdrDragMethod7DrawXorER13XOutputDevicei
+     10 _ZNK13SfxStringItem6CreateER8SvStreamt
+     45 _ZNK11CntBoolItem17GetValueTextByValEh
+     15 _ZTI12SvxColorItem
+