This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

The symbol auxiliary

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]