public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ro at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/50166] .init_array/.fini_array support doesn't work on Solaris
Date: Fri, 26 Aug 2011 14:36:00 -0000 [thread overview]
Message-ID: <bug-50166-4-20iVKBJilU@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-50166-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50166
Rainer Orth <ro at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Version|unknown |4.7.0
Last reconfirmed| |2011-08-26
Component|go |target
CC| |hjl at gcc dot gnu.org, ian
| |at airs dot com
AssignedTo|ian at airs dot com |ro at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|ICE in go1: SEGV on Solaris |.init_array/.fini_array
|10/x86 |support doesn't work on
| |Solaris
Target Milestone|--- |4.7.0
--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> 2011-08-26 14:23:51 UTC ---
The reghunt identified the culprit patch:
2011-08-20 H.J. Lu <hongjiu.lu@intel.com>
PR other/46770
* config.gcc (tm_file): Add initfini-array.h if
.init_arrary/.fini_array are supported.
[...]
The problem is that the test spuriously succeeds, but .init_array/.fini_array
support doesn't work as assumed:
If I add debug printf's to the ctors, dtors, and main, I find that only main
runs.
One problem with the test is that it fails to check that any of the destructors
have run. Unfortunately, it doesn't even work on CentOS 5.5 with mainline
gcc, gas and gld 2.21:
ctor1007 entry: count = 0
Aborted
so I'm not completely sure how it is supposed to work. At the very least, we
need
diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -477,6 +477,8 @@ void (*const dtors65535[]) ()
int
main ()
{
+ if (count != 65535)
+ abort ();
return 0;
}
#endif
or whatever value count is supposed to have here.
This patch at least allowed a successfull i386-pc-solaris2.11 bootstrap.
As for other issues with the testcase:
void (*const ctors65535[]) ()
__attribute__ ((section (".ctors"), aligned (sizeof (void *))))
= { ctor65535 };
leads to
.section .ctors,"a",@progbits
while using __attribute__ ((constructor) instead works. It has
.section .ctors,"aw",@progbits
crtbegin.o and crtend.o already have the latter form, and Sun ld only merges
input sections if all of sh_name, sh_flags, and sh_type match. The resulting
executable has two different .ctors sections, as can be seen with
> elfdump -N .ctors -c initfini
Section Header[24]: sh_name: .ctors
sh_addr: 0x8051084 sh_flags: [ SHF_ALLOC ]
sh_size: 0x4 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x1084 sh_entsize: 0
sh_link: 0 sh_info: 0
sh_addralign: 0x4
Section Header[32]: sh_name: .ctors
sh_addr: 0x8061260 sh_flags: [ SHF_WRITE SHF_ALLOC ]
sh_size: 0x8 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x1260 sh_entsize: 0
sh_link: 0 sh_info: 0
sh_addralign: 0x4
I don't know why __attribute__ ((section(".ctors)) creates a read-only section;
there seems no way to set a section's SECTION_WRITE flag.
The other problem with the testcase is the use of .ctors.<N> sections. AFAICT
the coalescing of .ctors.<N> sections into .ctors (and similar behavior for
.dtors.<N>, .init_array.<N> and .fini_array.<N>) is a GNU ld feature or
implementation detail not called for by the ELF gABI. Please point out where
this is specified if I'm wrong. Certainly, Sun ld (and SGI ld for that matter)
don't do this.
Rainer
next prev parent reply other threads:[~2011-08-26 14:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-23 15:50 [Bug go/50166] New: ICE in go1: SEGV on Solaris 10/x86 ro at gcc dot gnu.org
2011-08-24 18:08 ` [Bug go/50166] " ian at airs dot com
2011-08-25 13:57 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-08-26 14:36 ` ro at gcc dot gnu.org [this message]
2011-08-26 16:02 ` [Bug target/50166] .init_array/.fini_array support doesn't work on Solaris ro at gcc dot gnu.org
2012-02-17 16:04 ` ian at airs dot com
2012-02-17 17:55 ` ro at CeBiTec dot Uni-Bielefeld.DE
2012-02-22 22:05 ` jingyu at gcc dot gnu.org
2012-02-22 22:29 ` jingyu at gcc dot gnu.org
2012-03-22 8:35 ` rguenth at gcc dot gnu.org
2012-07-02 14:08 ` rguenth at gcc dot gnu.org
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=bug-50166-4-20iVKBJilU@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.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).