pending/1178: The symbol auxiliary

[Andrew Cagney <ac131313 at redhat dot com>]

>Number:         1178
>Category:       pending
>Synopsis:       The symbol auxiliary
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   unknown
>Arrival-Date:   Mon Apr 14 03:48:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 Thinking out loud.
 
 The architecture vector, using gdbarch_data(), lets modules add 
 additional, per-architecture information.
 
 I'm wondering if the symbol table should have something similar.  A 
 per-module symbol auxiliary table, indexed by the `struct symbol 
 address, that manages that modules symbol information.  The table would 
 be populated strictly on demand, and flushed when every the 
 corresponding symbol table was flushed (or when a memory crunch occured).
 
 For instance, the dwarf2cfi could use this as a clean way of retaining 
 the CFI information being loaded.  It can probably even extend to the 
 readers where info, such as what dwarf2loc needs, could be delayed until 
 needed.
 
 The assumption being that almost zero of the information currently being 
 read into the basic symbol table is used.  Instead of reading in all 
 that info, and wasting all that memory, the readers could pull in just 
 just the basics ([mangled] name, address, ???), and then read the rest 
 on on-demand.  While having symaux's would significantly increase the 
 the overhead of a fully loaded symbol, there would be so few that 
 nothing would notice.
 
 As for implementation, this could be done pretty much independant of the 
 main symbol table.  Just that `struct symbol' address is needed.
 
 Andrew
 
 
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: