This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1002013] New: [PATCH] gcc 4.7 breaks the synth


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]