Srikanth. 25th oct 2000.
=======================

This directory contains the files that implement the debugger support for
incrementally linked binaries on HP-UX 11.00 (64 bits.) At dart 52 time,
we have decided not to support incrementally linked binaries if they are
not compiled with +objdebug (doom) mode. Read below for the rationale.

	The files and their predecessors at this time are :

hp-psymtab-read.c predecessor version: /main/66
hp-symtab-read.c  predecessor version: /main/135
hpread.h          predecessor version: /main/10


	I am preserving this stuff here for posterity, rather than use a
branch or a view.

The reasons for this decision are :

   (1) This code was essentially developed on a branch in late 99. As a
result, it is incompatible with the performance tuning changes put in
place after wdb 1.2. In particular, it does not work with demand paging
off SLT, LNTT and incremental expansion of GNTT. There is no easy way to
reconcile this implementation to work with the just in time paging
algorithms and so Jimmy has chosen the short cut of disabling the
optimizations for ild binaries. Since it is reasonable to assume that
ild will be used only by large applications, the hit in terms of memory
usage and runtime will be felt most here.

    (2) The non-doom code is very heuristic driven. There are a bunch of
rules of thumb used to decide if a given psymtab has been overridden by
later incremental builds. These heuristics look reasonable in
themselves, but these depend on the linker symbol table which it itself
may be in an inconsistent state. See (5) below.

    (3) Performance of algorithms : Some of the algorithms are expensive
as they involve repeated exhaustive searches of the global symbol table
to see if a later "chapter" overrides the current symbol. This has to be
done for every global symbol from an earlier chapter. This is not the
same as (1) above. In the absence of real large test cases, it is hard
to set expectations for memory usage and performance issues.

    (4) Lastly my pet peeve : This causes significant code clutter,
introducing additional layers of indirection and the attendant code
complexity. The data structures that we depend on are in an inconsistent
state in the load module and we need to use heuristics to recover. In
particular, pxdb has been run only on the first link and after an
incremental link, the quick lookup tables are bound to be inconsistent.
This also changes the guts of the symbol table internalization
algorithms.

I agree that this in itself does not mean much : If we want to support
evolving functionality in our partners, we need to cope with complexity.
All the same, I think this is important enough to ponder.

    (5) Correctness issues : This applies to both modes. One of the
assumptions Rajiv was working on was that, the linker symbol table is
always up to date. This is not true according to the linker team. As a
result, we do see old junky symbols in the linker symbol table.
Curiously this does not impact them at all as the linker never asks the
question, given a PC, what is the symbol. The debugger does this all the
time. As a result, we sometimes claim the program is stopped in foo()
while it is actually stopped somewhere else. I think it could be harder
to solve this problem for non-doom than for doom.

    In contrast, I think the doom mode only implementation is much
cleaner and really small.

 
