public inbox for ecos-bugs@sourceware.org help / color / mirror / Atom feed
From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1002013] New: [PATCH] gcc 4.7 breaks the synth Date: Thu, 02 Oct 2014 07:47:00 -0000 [thread overview] Message-ID: <bug-1002013-13@http.bugs.ecos.sourceware.org/> (raw) Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=1002013 Bug ID: 1002013 Summary: [PATCH] gcc 4.7 breaks the synth Product: eCos Version: CVS Target: linux (Linux synthetic target) Architecture/Host HostOS: Linux OS: Status: NEW Severity: normal Priority: low Component: HAL Assignee: unassigned@bugs.ecos.sourceware.org Reporter: wry@ecoscentric.com CC: ecos-bugs@ecos.sourceware.org Flags: Patch_or_Contribution+ Created attachment 2541 --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2541&action=edit Patch that fixes the synth HAL (Have discussed with jifl.) Perhaps foolhardily, I upgraded my desktop from Ubuntu 12.04 to 14.04. Long story short: * Ubuntu 14.04 ships with gcc 4.8 out of the box. * On an image for the synthetic target compiled with 4.8, __CTOR_LIST__ == __CTOR_END__. * In other words, none of our static constructors run, leaving a badly broken universe. (Simple example: The kernel test thread1 (amongst others) crashes with a segfault when it attempts to resume a thread.) * Compiling the same test code with gcc 4.6 on the same system works just fine. On further investigation, the relevant change was made in gcc 4.7, which was to rename the .ctors section of the ELF image to .init_array (and to present its members in the opposite order). Patch attached; tested with both gcc 4.6 and 4.8. This looks for both .ctors and .init_array sections and iterates through them both; it's very similar to the code in the ARM HAL which incurred this issue on the change to EABI. But I think that autodetecting on the synth is a better answer than a CDL option to switch between the two (cf. EABI); it is not exactly a resource-constrained target so the extra code size is harmless. I suspect the i386 HAL will require a similar patch, but I do not have access to a suitable test rig at the present time. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2014-10-02 7:47 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-10-02 7:47 bugzilla-daemon [this message] 2014-10-03 15:14 ` [Bug 1002013] " bugzilla-daemon -- strict thread matches above, loose matches on Subject: below -- 2014-10-02 7:47 [Bug 1002013] New: " bugzilla-daemon
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-1002013-13@http.bugs.ecos.sourceware.org/ \ --to=bugzilla-daemon@bugs.ecos.sourceware.org \ --cc=ecos-bugs@ecos.sourceware.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: linkBe 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).