public inbox for ecos-bugs@sourceware.org
help / color / mirror / Atom feed
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@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-777@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 the assignee for the bug.


             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-777@http.bugs.ecos.sourceware.org/ \
    --to=bugzilla-daemon@bugs.ecos.sourceware.org \
    --cc=unassigned@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: 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).