From: Kito Cheng <kito@0xlab.org>
To: binutils@sourceware.org, Ian Lance Taylor <iant@google.com>
Cc: Jim Huang <jserv@0xlab.org>
Subject: [PATCH] Prevent broken sysv-style hash table when --hash-style=both
Date: Tue, 17 Jan 2012 20:35:00 -0000 [thread overview]
Message-ID: <CA+yXCZCbS46y4i6gv_mFAJjnVh8QHHr=tD89WwHrRj7TYc4hGg@mail.gmail.com> (raw)
The root cause seem the gold::Dynobj::create_gnu_hash_table will
change the dynsym_index,
so this patch just reorder the symbol table generate order to
guarantee the gold::Dynobj::create_elf_hash_table get correct
dynsym_index.
However it's will change the section order between .hash and
.gnu.hash, any suggestion ?
[1] http://sourceware.org/bugzilla/show_bug.cgi?id=13597
Index: gold/layout.cc
===================================================================
RCS file: /cvs/src/src/gold/layout.cc,v
retrieving revision 1.222
diff -r1.222 layout.cc
3835c3835
< if (strcmp(parameters->options().hash_style(), "sysv") == 0
---
> if (strcmp(parameters->options().hash_style(), "gnu") == 0
3840c3840
< Dynobj::create_elf_hash_table(*pdynamic_symbols, local_symcount,
---
> Dynobj::create_gnu_hash_table(*pdynamic_symbols, local_symcount,
3844c3844
< this->choose_output_section(NULL, ".hash", elfcpp::SHT_HASH,
---
> this->choose_output_section(NULL, ".gnu.hash", elfcpp::SHT_GNU_HASH,
3859,3860d3858
< hashsec->set_entsize(4);
< }
3862,3863c3860,3868
< if (odyn != NULL)
< odyn->add_section_address(elfcpp::DT_HASH, hashsec);
---
> // For a 64-bit target, the entries in .gnu.hash do not have
> // a uniform size, so we only set the entry size for a
> // 32-bit target.
> if (parameters->target().get_size() == 32)
> hashsec->set_entsize(4);
>
> if (odyn != NULL)
> odyn->add_section_address(elfcpp::DT_GNU_HASH, hashsec);
> }
3866c3871
< if (strcmp(parameters->options().hash_style(), "gnu") == 0
---
> if (strcmp(parameters->options().hash_style(), "sysv") == 0
3871c3876
< Dynobj::create_gnu_hash_table(*pdynamic_symbols, local_symcount,
---
> Dynobj::create_elf_hash_table(*pdynamic_symbols, local_symcount,
3875c3880
< this->choose_output_section(NULL, ".gnu.hash", elfcpp::SHT_GNU_HASH,
---
> this->choose_output_section(NULL, ".hash", elfcpp::SHT_HASH,
3890,3898c3895
<
< // For a 64-bit target, the entries in .gnu.hash do not have
< // a uniform size, so we only set the entry size for a
< // 32-bit target.
< if (parameters->target().get_size() == 32)
< hashsec->set_entsize(4);
<
< if (odyn != NULL)
< odyn->add_section_address(elfcpp::DT_GNU_HASH, hashsec);
---
> hashsec->set_entsize(4);
3899a3897,3899
>
> if (odyn != NULL)
> odyn->add_section_address(elfcpp::DT_HASH, hashsec);
next reply other threads:[~2012-01-17 20:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-17 20:35 Kito Cheng [this message]
2012-01-17 20:56 ` Mike Frysinger
2012-01-17 21:10 ` Kito Cheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+yXCZCbS46y4i6gv_mFAJjnVh8QHHr=tD89WwHrRj7TYc4hGg@mail.gmail.com' \
--to=kito@0xlab.org \
--cc=binutils@sourceware.org \
--cc=iant@google.com \
--cc=jserv@0xlab.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).