This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 4/7] Class-fy partial_die_info
Simon Marchi <simark@simark.ca> writes:
> From what I understand, the only reason to have that private constructor is
> to construct a temporary partial_die_info object used to search in the htab,
> is that right? If so, converting that htab_t to an std::unordered_map would
Right.
>
> - /* Hash table holding all the loaded partial DIEs
> - with partial_die->offset.SECT_OFF as hash. */
> - htab_t partial_dies = nullptr;
> + /* Hash map holding all the loaded partial DIEs
> + with their section offset as the key. */
> + std::unordered_map<sect_offset, partial_die_info *> partial_dies;
>
This doesn't compile with my g++ 4.9, as library doesn't provide
std::hash<T> specialization for enumeration types. It is available
since C++ 14. http://en.cppreference.com/w/cpp/utility/hash
I can change it to
std::unordered_map<std::underlying_type<sect_offset>::type,
partial_die_info *> partial_dies;
to fix the compiler errors.
> @@ -18259,14 +18227,7 @@ load_partial_dies (const struct die_reader_specs *reader,
> if (cu->per_cu->load_all_dies)
> load_all = 1;
>
> - cu->partial_dies
> - = htab_create_alloc_ex (cu->header.length / 12,
> - partial_die_hash,
> - partial_die_eq,
> - NULL,
> - &cu->comp_unit_obstack,
> - hashtab_obstack_allocate,
> - dummy_obstack_deallocate);
> + cu->partial_dies.clear ();
This changes the behavior, without this patch, cu->partial_dies's
elements are allocated on cu->comp_unit_obstack. After this patch,
elements are allocated on heap. I don't know how does it affect
performance.
--
Yao (齐尧)