Re: [PATCH 3/3] Cache the result of find_file_and_directory

[Tom Tromey <tom@tromey.com>]

Simon> Thanks.  And while looking at that fix, I had this this question:
Simon> looking at find_file_and_directory:

Simon>       file_and_directory res (dwarf2_string_attr (die, DW_AT_name, cu),
Simon>     			  dwarf2_string_attr (die, DW_AT_comp_dir, cu));

Simon> `dwarf2_string_attr (die, DW_AT_name, cu)` is used as the name in
Simon> `fnd`, and `fnd` is saved in the dwarf2_per_cu_data structure.  Is
Simon> `dwarf2_string_attr (die, DW_AT_name, cu)` value guaranteed to live at
Simon> least as long as the dwarf2_per_cu_data structure?

Yeah.  The string data is mapped either from the .debug_str (normally)
or .debug_info (for very short strings, sometimes) section.  The section
data is only unmapped when the per-BFD is destroyed, i.e., when the last
reference is removed.  (There are other cases here, the section data
might be allocated and freed per-objfile if it has relocations, but
again, it's long enough.)

There are cases where the string data is manipulated first -- C++ name
canonicalization (I can't think of another case but maybe there are
some).  However, when this is done, the resulting string is stored
somewhere with the appropriate lifetime, normally the per-BFD obstack.

Tom