This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: remove partial_symtab::objfile
>>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:
Yao> It is a cleanup to me. What is "symbol table location independence"?
Yao> Do we have the description or discussion on it some where?
It's come up a few times on the list.
The basic idea is that, in most cases, all the data read by the symbol
readers is read-only and could be shared between inferiors. This would
be desirable for multi-inferior debugging, particularly when the various
inferiors all use common shared libraries.
The main barrier to having this work is that section offsets are added
into the symbol addresses when the symbols are created.
So, the idea is to change the readers not to do this, and to change the
code to apply the offsets at runtime. Then the symbol data can be moved
into struct objfile_per_bfd_storage and automatically shared.
One problem for this idea is that dlmopen means that a given file may be
mapped more than once in a given inferior. So in this case, things like
lookup_minimal_symbol are a problem -- it can't just return a pointer to
the unrelocated minimal symbol. I think here we'll need a "bound
symbol" that also carries its objfile along with it. So, a pretty big
change overall :-(
It turns out that it is simplest to do this sharing for partial symbols,
since they don't escape the psymtab module.
I've worked on this project on and off over the last few years, with a
few failures along the way. I've come to view it as a long term thing,
mostly out of necessity :(
>> @@ -2050,13 +2045,13 @@ xcoff_start_psymtab (struct objfile *objfile,
>> are the information for includes and dependencies. */
>>
>> static struct partial_symtab *
>> -xcoff_end_psymtab (struct partial_symtab *pst, const char **include_list,
>> +xcoff_end_psymtab (struct objfile *objfile,
>> + struct partial_symtab *pst, const char **include_list,
>> int num_includes, int capping_symbol_number,
>> struct partial_symtab **dependency_list,
>> int number_dependencies, int textlow_not_set)
Yao> Why write in this way? to reduce the length of patch? or some other reason?
Yeah, just to avoid reformatting.
I will rearrange it.
Tom