Re: [RFC-v4] Fix .text section offset for windows DLL (was Calling __stdcall functions in the inferior)

[Tom Tromey <tromey@redhat.com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel>    prim_record_minimal_symbol
Joel> -> prim_record_minimal_symbol_full with copy_name=1
Joel> -> SYMBOL_SET_NAMES (msymbol, name, name_len, copy_name, objfile);

Joel> |  else
Joel> |    {
Joel> |      lookup_len = len;
Joel> |      lookup_name = linkage_name;
Joel> |      linkage_name_copy = linkage_name;
Joel> |    }
Joel> |
Joel> |  entry.mangled = (char *) lookup_name;
Joel> |  slot = ((struct demangled_name_entry **)
Joel> |          htab_find_slot (objfile->demangled_names_hash,
Joel> |                          &entry, INSERT));

Joel> Does it looks like a reference to the string might actually
Joel> get inserted in the htab if not found, thus defeating the
Joel> mechanism above? Tom might be better suited to answer that
Joel> question more authoritatively.

Here, 'entry' is used to look in the hash table, but it is not entered
into the hash table itself.  For that you have to go into the subsequent
"*slot == NULL" code; and there it allocates a new entry on the
objfile's obstack.  There are two cases, but e.g.:

	  *slot = obstack_alloc (&objfile->objfile_obstack,
				 offsetof (struct demangled_name_entry,
					   demangled)
				 + demangled_len + 1);

Joel> In the meantime, one approach that might be equally suitable, but
Joel> without the bug, is if allocate the name on the objfile obstack,
Joel> and then call prim_record_minimal_symbol_full directly

I think there's no need; this is what the 'copy_name=1' case is for.

Tom