public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Help needed in output relocations
@ 2023-10-18 14:33 Rishi Raj
  2023-10-18 15:30 ` Jan Hubicka
  0 siblings, 1 reply; 2+ messages in thread
From: Rishi Raj @ 2023-10-18 14:33 UTC (permalink / raw)
  To: Martin Jambor, Jan Hubicka, gcc

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

Hello,
I have almost completed the output of relocation entries. The only thing
that remains is to output the corresponding symbols in .symtab. In my
current design, I store the info about relocation entry and the symbol
name. However, the problem I am facing with this approach is that many
relocation entries will have the same name, so we will need a hash table
with the key as symbol name and value as symbol index in symtab. It would
be really helpful if you could point out the relevant docs or help me
figure out how to use the hash table in GCC.
Another approach is, as we have only 4-5 unique relocation symbol names. We
can output just those and store their .symtab index somewhere.

--
Rishi

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Help needed in output relocations
  2023-10-18 14:33 Help needed in output relocations Rishi Raj
@ 2023-10-18 15:30 ` Jan Hubicka
  0 siblings, 0 replies; 2+ messages in thread
From: Jan Hubicka @ 2023-10-18 15:30 UTC (permalink / raw)
  To: Rishi Raj; +Cc: Martin Jambor, gcc

> Hello,
Hi,
> I have almost completed the output of relocation entries. The only thing
> that remains is to output the corresponding symbols in .symtab. In my
> current design, I store the info about relocation entry and the symbol
> name. However, the problem I am facing with this approach is that many
> relocation entries will have the same name, so we will need a hash table
> with the key as symbol name and value as symbol index in symtab. It would
> be really helpful if you could point out the relevant docs or help me
> figure out how to use the hash table in GCC.
> Another approach is, as we have only 4-5 unique relocation symbol names. We
> can output just those and store their .symtab index somewhere.

I am not 100% sure what precisely you need, but if you need just
hashtable translating strings to integers, you can probably just
follow section_name_hash in symtab.cc which is doing pretty much
the same.

In case you can already rely on the fact that the strings are unified
(which is the case for GCC's identifiers) you can also simply use
hash_map<tree,unsigned_int> which has bit easier to set up.

Honza
> 
> --
> Rishi

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-10-18 15:30 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-18 14:33 Help needed in output relocations Rishi Raj
2023-10-18 15:30 ` Jan Hubicka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).