This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: MIPS multi-got link support
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: binutils at sources dot redhat dot com
- Date: 19 Jan 2003 09:03:38 -0200
- Subject: Re: MIPS multi-got link support
- Organization: GCC Team, Red Hat
- References: <Pine.BSF.4.44.0301161334240.14615-100000@dair.pair.com>
On Jan 16, 2003, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> On 16 Jan 2003, Alexandre Oliva wrote:
>> The main problem is that we have
>> hashtables that use pointers to bfds as (part of) keys, and then the
>> process of bfd->got mapping, as well as the ordering of relocations
>> and got entries, ends up dependent on the exact addresses of bfds.
> Now *there's* a reason to scream. (For the curious as to why,
> except for the regression test-suite: How would one handle a
> bug-report related to this code?)
Erhm... Telling the user to rebuild ld with different optimization
options? :-P :-D
Ok, I'm willing to remove the uses of htab_hash_pointer, but I'd
really really like to do it after this bulky patch goes in. The
change will also affect code that is already in, so it's not like the
patch is breaking new grounds in this sense.
However, I'd appreciate suggestions on what fields of a bfd to use to
compute its hash code. There doesn't seem to be a bfd unique
identifier, and I'm not sure whether a number of its fields that could
be used for hash functions are guaranteed to remain constant during
linking. So far, I've only identified the filename as a safe
hash-able value. It appears to me that all of section_count, symcount
and section_htab.size may change. Right?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer