Bug 91056 - RHEL3 a4: gcc violates the ia64 ABI
RHEL3 a4: gcc violates the ia64 ABI
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gcc (Show other bugs)
3.0
ia64 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
: 91140 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-16 17:31 EDT by hjl
Modified: 2007-11-30 17:06 EST (History)
5 users (show)

See Also:
Fixed In Version: 3.2.3-12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-08-05 12:27:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
A small testcase (51 bytes, text/plain)
2003-05-16 17:34 EDT, hjl
no flags Details
note.txt (3.19 KB, text/plain)
2003-06-30 16:52 EDT, Larry Troan
no flags Details
rfc.txt (2.07 KB, text/plain)
2003-06-30 16:53 EDT, Larry Troan
no flags Details

  None (edit)
Description hjl 2003-05-16 17:31:34 EDT
According to the ia64 ABI, callee can change gp and gp must be
saved by caller. But gcc doesn't save/store gp across call.
Comment 1 hjl 2003-05-16 17:34:47 EDT
Created attachment 91748 [details]
A small testcase

With "gcc -S -O2 x.c", I got

	.file	"x.c"
	.pred.safe_across_calls p1-p5,p16-p63
	.text
	.align 16
	.global bar#
	.proc bar#
bar:
	.prologue
	.body
	.bbb
	nop 0
	nop 0
	br.sptk.many foo#
	;;
	break.f 0
	;;
	.endp bar#
	.ident	"GCC: (GNU) 3.2.3 20030422 (Red Hat Linux 3.2.3-3)"

gp is not preserved.
Comment 2 Jakub Jelinek 2003-05-16 17:53:15 EDT
And the problem is? The caller doesn't use gp at all, so it doesn't have to restore it.
Its caller is supposed to restore gp if it uses it.
Also, your example is a tail call, so there really must not be any gp restoring.
Comment 3 hjl 2003-05-16 18:21:03 EDT
On page 5-2 in Itanium Software Conventions and Runtime Architecture
Guide, there are

...
a. On entry to a procedure, gp is guaranteed valide for that procedure.
b. At any direct procedure call, gp must be valid (for the caller). This
guarantees that an import stub (see Section 8.4.1) can access the linkage
table.
c. Any procedure call (indirect or direct) may modify gp - unless the call
is known to be local to the load module.
d. At procedure return, gp must be valid (for the returning prodecure).
This allows the compiler to optimize calls known to be local (i.e., the
exceptions to Rule 'c').

The effect of the rules is that gp must be treated as scratch register
at the point of call (i.e., it must be saved by the caller), and it must
be preserved from entry to exit.

Since bar () may modify gp, at the return of foo, gp must be valid for foo
even if foo doesn't use gp at all. Did I miss something here?
Comment 4 Larry Troan 2003-05-19 14:32:45 EDT
THIS IS ISSUE TRACKER 22133 opened as sev 2 on 5/18/03.
Comment 5 Larry Troan 2003-05-19 14:37:29 EDT
*** Bug 91140 has been marked as a duplicate of this bug. ***
Comment 6 Larry Troan 2003-06-30 16:51:44 EDT
FROM ISSUE TRACKER....
Event posted 06-28-2003 11:40am by hongjiu.lu with duration of 0.00        
This bug is very serious and affects all ia64 compilers, Intel compiler, HP
compiler and gcc. We need a way to tell if a .o file preserves GP or not.
Richard Henderson proposed to use a bit in e_flags in ELF header. Both Intel and
HP feel a note section is more appropriate.

I am uploading Intel's proposal. Intel will provide a patch for linker. If
necessry, Intel will provide a gcc patch to generate the note section.    

--------------------
Event posted 06-28-2003 11:41am by hongjiu.lu with duration of 0.00
note.txt
This is a proposal to add a property note section to .o file.

File uploaded: note.txt    

-----------------------
Event posted 06-28-2003 11:44am by hongjiu.lu with duration of 0.00
rfc.txt
This is a proposal to add a property note section to .o file. In another file,
we propose a NT_GNU_PROPETRTY_IA_64_PRESERVE_GP bit in the property note section
to indicate if a .o file preserves GP or not.

File uploaded: rfc.txt
Comment 7 Larry Troan 2003-06-30 16:52:41 EDT
Created attachment 92695 [details]
note.txt
Comment 8 Larry Troan 2003-06-30 16:53:03 EDT
Created attachment 92696 [details]
rfc.txt
Comment 9 Jakub Jelinek 2003-06-30 18:37:19 EDT
I think Richard was quite clear why he prefers e_flags:
http://sources.redhat.com/ml/binutils/2003-06/msg00217.html
Comment 10 hjl 2003-06-30 20:02:11 EDT
I askd Richard about the impact of e_flags change:

http://sources.redhat.com/ml/binutils/2003-06/msg00224.html

Neither Intel compiler group nor HP compiler group believe changing e_flags
is the right solution. A note section should be used in this case. Intel
made a proposal and can provide resources to work on this issue.
Comment 11 Larry Troan 2003-07-07 18:28:05 EDT
QUESTION FROM ISSUE TRACKER 22133 WHOSE ORIGINAL BUGZILLA (91140) WAS MARKED AS
A DUP OF THIS BUG.

Event posted 05-19-2003 10:45am by hongjiu.lu with duration of 0.00        
This bug has been there for a long time. It was discovered on
AS 2.1 last week and I don't think it it is changed in Red Hat
EL 3.0 Alpha 3.

-----------------
QUESTION ON THE TABLE IS WHETHER RH AGREES WITH INTEL/HP RECOMMENDATION THAT A
NOTE IS APPROPRIATE... per hjl@gnu.org's comment of 6/30/03. If not, then do we
plan to implement the recommended fix or propose an alternate action?
Comment 12 Larry Troan 2003-07-14 15:09:58 EDT
Intel is asking for a Red Hat position on this....
1) Note
2) Accept their patch
3) Propose alternative action (patch/doc/???)
Comment 13 Larry Troan 2003-07-16 11:10:19 EDT
FROM ISSUE TRACKER.........
Event posted 07-14-2003 03:30pm by hongjiu.lu with duration of 0.00
Intel has looked into the e_flags solution. We have several concerns:

1. How will gcc generate a .o file with the new e_flags?
2. Is a new assembler needed? Is a new assembler option needed?
3. What should the default e_flags for assembler and linker be?
4. What changes are required for glibc and kernel?
5. What changes are required for the third-party tools?

We were afraid the e_flags approach might be too intrusive. Also
the e_flags change is the ia64 psABI change, which requires
agreement from all tool vendors. Since it is a gcc specific bug,
it may not be easy to get OK from all other tool vendors. If we
do decide to go the e_flags route, we should be prepared to present
a strong case to the ia64 psABI committee as well as glibc and kernel
people if their changes are needed.
Comment 14 Richard Henderson 2003-07-16 13:27:43 EDT
> 1. How will gcc generate a .o file with the new e_flags?
> 2. Is a new assembler needed? Is a new assembler option needed?

With an assembler directive, so yes, a new assembler would be needed.

> 3. What should the default e_flags for assembler and linker be?

Unset.

> 4. What changes are required for glibc and kernel?

None that I know of.

> 5. What changes are required for the third-party tools?

Depends on what they do with object files, or code generation.

> Since it is a gcc specific bug, it may not be easy to get OK from
> all other tool vendors.  If we do decide to go the e_flags route,
> we should be prepared to present a strong case to the ia64 psABI
> committee as well as glibc and kernel people if their changes are needed.

I understand this, but I still think that it's worth while.

In the short term I plan on changing gcc so that we do not generate
tail-calls.  I will not change gcc to take advantage of the knowledge
that local calls cannot modify the GP.  This means that gcc's output
will be compatible with both icc and older gcc output.  There will be
no flags or magic sections or anything associate with this change.

In the long term, I'd still like to see the psABI change to accomodate
languages that REQUIRE tail call optimizations, such as Scheme, ML,
Mercury, and other functional/logical languages.  Further, it is my
guess (unbacked by hard data) that tail call optimizations are more
useful to ia64 than avoiding gp reloads.

Comment 15 Richard Henderson 2003-07-17 15:44:43 EDT
Patch applied for gcc 3.3.1; needs merging to appropriate RH branches.
Comment 16 Larry Troan 2003-08-04 14:34:42 EDT
FROM ISSUE TRACKER.....
Event posted 07-25-2003 11:13am by hongjiu.lu with duration of 0.00
Will beta2 have the new gcc? Another issue is unless all .a archives in beta2 are
recompiled by the new gcc, we still can't assume GP will be preserved in beta2.
Comment 17 Larry Troan 2003-08-04 18:28:04 EDT
ADDITIONAL COMMENTS FROM THE INTEL CALL TODAY...
Intel informs us that at least glibc will need to be recompiled when gcc is
updates. They recommend recompiling the entire platform to insure all components
pick up the gcc patch. Can we do this for Beta2?
Comment 18 Jakub Jelinek 2003-08-05 12:27:25 EDT
Already Taroon beta1 has this gcc.
As for rebuilding everything, I'm afraid it is not going to happen.
Some libraries surely will (or already have been rebuilt), including glibc.

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