Bug 42557 - PPC HAL needs cleanup to adhere to ABI/EABIs
PPC HAL needs cleanup to adhere to ABI/EABIs
Product: eCos
Classification: Retired
Component: HAL (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: ecc-bugs-int
Depends On:
  Show dependency treegraph
Reported: 2001-05-28 06:15 EDT by Jesper Skov
Modified: 2007-04-18 12:33 EDT (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description Jesper Skov 2001-05-28 06:15:51 EDT
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

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.

Comment 1 Alex Schuilenburg 2003-06-20 12:00:33 EDT
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.