Bug 42557 - PPC HAL needs cleanup to adhere to ABI/EABIs
Summary: PPC HAL needs cleanup to adhere to ABI/EABIs
Status: CLOSED WONTFIX
Alias: None
Product: eCos
Classification: Retired
Component: HAL   
(Show other bugs)
Version: CVS
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: ecc-bugs-int
QA Contact: ecc-bugs-int
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-05-28 10:15 UTC by Jesper Skov
Modified: 2007-04-18 16:33 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-20 16:00:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jesper Skov 2001-05-28 10:15:51 UTC
Paul> Main question I have for you guys is to understand in the case
Paul> of the PPC what the extra effort would be if we had to use the
Paul> PPC Linux as apposed to EABI compiler?
>>  I think we concluded last week this would make no difference. We
>> already use a PPC Linux compiler for eCos PPC boards in the farm
>> right now, apparently.
>> 
>> But we'd want to check the ABI differences and make sure. If there
>> are any changes, the code could be fixed in a matter of minutes.

Paul> Nick seemed to have an about turn and think this could
Paul> potentially be pretty far reaching - especially the MIPS arch -
Paul> v.different ABI due to PIC/PID, etc?

Paul> Pls check PPC Linux compiler usage...

I've looked at the PPC EABI which is an extension of the SVR4
ABI. There are no changes to use of registers in calls.

In SVR4 the stack pointer must always be 16-byte aligned, while in the
EABI it only needs to be 8-byte aligned. I believe we may actually
leave it only 4-byte aligned in some situations, so that would need
fixing (and according to the ABI in effect).

There are similar alignment differences for aggregate and long data
types, so we (I) should double check the linker script alignment
statements. 

Finally, we don't initialize GPR13 as required by both ABIs, and I
suspect the linker script also botches on the definition of the symbol
used for initializing GPR2 which is a requirement in the EABI.  Again,
something that needs to be cleaned up and made dynamic based on the
ABI in effect.

I'm opening a bug on these issues.

Jesper

Comment 1 Alex Schuilenburg 2003-06-20 16:00:33 UTC
This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id=42557


Note You need to log in before you can comment on or make changes to this bug.