Discussion:
PATCH: Support the .note.GNU-property section
(too old to reply)
H. J. Lu
2003-06-05 00:34:34 UTC
Permalink
This patch implements the .note.GNU-property section I proposed. It
works on Linux/ia32 and Linux/ia64.


H.J.
Nick Clifton
2003-06-05 09:11:36 UTC
Permalink
Hi H.J.
Post by H. J. Lu
This patch implements the .note.GNU-property section I proposed. It
works on Linux/ia32 and Linux/ia64.
I would prefer holding off applying this patch until we have a use for
it. Otherwise it would just bit rot away over time.

Cheers
Nick
H. J. Lu
2003-06-05 14:46:04 UTC
Permalink
Post by Nick Clifton
Hi H.J.
Post by H. J. Lu
This patch implements the .note.GNU-property section I proposed. It
works on Linux/ia32 and Linux/ia64.
I would prefer holding off applying this patch until we have a use for
it. Otherwise it would just bit rot away over time.
As you may know, the current gcc violates the ia64 psABI by not
preserving gp across function calls. The relocatable file created by
the current gcc may not be binary compatible with the relocatable
file generated by other ia64 psABI conforming compilers. The result
is we may get random run-time failure. We'd like to have a way to
detect such a condition. Here is one way to do that using the
.note.GNU-property section.


H.J.
-----
Marking ia64 psABI conformance in relocatable files

On page 5-2 in Itanium Software Conventions and Runtime Architecture
Guide, there are

...
a. On entry to a procedure, gp is guaranteed valid 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 procedure). 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.

The current gcc doesn't follow Rule `d' for external tail call and gp may not be valid when call returns. It isn't a problem for gcc since gcc doesn't optimize gp for calls known to be local according to the exceptions to Rule `c'. But it may be a serious problem when mixing relocatable files compiled by gcc and by other psABI conforming compilers.

Considering 2 relocatable files, one is compiled by gcc and has the definition of a procedure, foo, which has tail call to an external procedure, bar, the other is compiled by a psABI conforming compiler and references foo, the psABI conforming compiler may skip reloading gp across calls to foo if foo is marked local by symbol visibility. When those 2 files are linked together, the resulting output may have corrupted gp when calls to bar return if bar uses a different gp.

Static executables aren't affected by this since gp is constant. This problem only happens when relocatable files are mixed together to generate dynamic executables and shared libraries. We need a way to detect such cases. We use the optional GNU property note section, ".note.GNU-property ", for compiler to store ia64 psABI compliance information for relocatable files. The contents of this note section are:

.section .note.GNU-property
.align 4
data4 .L1 - .L0
data4 .L3 - .L2
data4 1
.L0:
stringz "GNU property"
.L1:
.align 4
.L2:
data4 gflags
data4 psflags
.L3:
.align 4

The valid bit in psflags is

#define NT_GNU_PROPETRTY_IA_64_PRESERVE_GP (0x1 << 0)

If this bit is set, gp is preserved in procedure from entry to exit in this relocatable file.

If a linker supports the optional GNU property note section, it should follow the rules below when processing the relocatable input for generating relocatable file, dynamic executable or shared library:

1. Linker should detect function or no-type definition with non-default visibility in executable section if the note section is missing or the NT_GNU_PROPETRTY_IA_64_PRESERVE_GP bit is not set.
2. The note section should be removed from the output when generating executable or shared library.
3. The note section should be preserved to the output relocatable file only if all input relocatable files have the note section and the bit in psflags should be set only if it is set in all input relocatable files.
Jakub Jelinek
2003-06-05 14:49:37 UTC
Permalink
Post by H. J. Lu
Post by Nick Clifton
Hi H.J.
Post by H. J. Lu
This patch implements the .note.GNU-property section I proposed. It
works on Linux/ia32 and Linux/ia64.
I would prefer holding off applying this patch until we have a use for
it. Otherwise it would just bit rot away over time.
As you may know, the current gcc violates the ia64 psABI by not
preserving gp across function calls. The relocatable file created by
the current gcc may not be binary compatible with the relocatable
file generated by other ia64 psABI conforming compilers. The result
is we may get random run-time failure. We'd like to have a way to
detect such a condition. Here is one way to do that using the
.note.GNU-property section.
On the other side, IA-64 does not need PT_GNU_STACK handling, since
its trampolines don't need executable stack.

Jakub
H. J. Lu
2003-06-05 14:53:51 UTC
Permalink
Post by Jakub Jelinek
Post by H. J. Lu
Post by Nick Clifton
Hi H.J.
Post by H. J. Lu
This patch implements the .note.GNU-property section I proposed. It
works on Linux/ia32 and Linux/ia64.
I would prefer holding off applying this patch until we have a use for
it. Otherwise it would just bit rot away over time.
As you may know, the current gcc violates the ia64 psABI by not
preserving gp across function calls. The relocatable file created by
the current gcc may not be binary compatible with the relocatable
file generated by other ia64 psABI conforming compilers. The result
is we may get random run-time failure. We'd like to have a way to
detect such a condition. Here is one way to do that using the
.note.GNU-property section.
On the other side, IA-64 does not need PT_GNU_STACK handling, since
its trampolines don't need executable stack.
It is trivial to overwrite gflags and psflags for a backend. You just
define elf_backend_[copy|merge|print]_[target_]property. One more
benefit of my .note.GNU-property proposal.


H.J.
Jim Wilson
2003-06-05 17:32:19 UTC
Permalink
Wouldn't it be easier to just fix the IA-64 gcc port to be ABI compliant?

There are two issues here
1) We need to restore gp in epilogue in some cases where we currently do
not. This is a correctness issue.
2) We can optimize away gp save/restore around calls functions in the
same load module. This is an optimization.

The first one does not cause any ABI problems. The second one does, and
can only be implemented after the first one.

So a possible solution is to implement the first change now, wait a year
or two, and then implement the second one. After the second change, we
can document that the next version of gcc is ABI incompatible with older
linux releases. There will be 3 or 4 version numbers between
incompatible versions, so this shouldn't be a fatal problem. We could
even add an option to disable the optimization for people that need
compatibility. Of course, this requires long term planning which we
aren't very good at.

Jim
H. J. Lu
2003-06-05 17:50:52 UTC
Permalink
Post by Jim Wilson
Wouldn't it be easier to just fix the IA-64 gcc port to be ABI compliant?
There are two issues here
1) We need to restore gp in epilogue in some cases where we currently do
not. This is a correctness issue.
2) We can optimize away gp save/restore around calls functions in the
same load module. This is an optimization.
The first one does not cause any ABI problems. The second one does, and
can only be implemented after the first one.
So a possible solution is to implement the first change now, wait a year
or two, and then implement the second one. After the second change, we
can document that the next version of gcc is ABI incompatible with older
linux releases. There will be 3 or 4 version numbers between
incompatible versions, so this shouldn't be a fatal problem. We could
even add an option to disable the optimization for people that need
compatibility. Of course, this requires long term planning which we
aren't very good at.
Thanks for your comment. The goal of my proposal is to help to do
what you have suggested. The problem my propoal is trying to address
is, even if we fix gcc to preserve gp, but there is no way to tell if
a .o file generated by gcc is ABI conforming or not. For a function
with hidden/internal/protected visibility, gcc can do optimization you
suggested in 2) since the function will be in the same load module.
But it isn't safe without knowing if a .o file is ABI conforming or
not. With my proposal, the .o files generated by ABI conforming
compiler will have the NT_GNU_PROPETRTY_IA_64_PRESERVE_GP set and
the linker can use it to detect the possible run-time failure and
issue a warning.


H.J.
Richard Henderson
2003-06-05 21:06:17 UTC
Permalink
But it isn't safe without knowing if a .o file is ABI conforming or not.
Correct.
With my proposal, the .o files generated by ABI conforming
compiler will have the NT_GNU_PROPETRTY_IA_64_PRESERVE_GP set and
the linker can use it to detect the possible run-time failure and
issue a warning.
All such .o files? Meaning that you'll get Intel and HP and (...)
to change their object file generation?

Anyway, for something this platform specific, you might as well use
an e_flags bit.


r~
H. J. Lu
2003-06-05 22:11:37 UTC
Permalink
Post by Richard Henderson
But it isn't safe without knowing if a .o file is ABI conforming or not.
Correct.
With my proposal, the .o files generated by ABI conforming
compiler will have the NT_GNU_PROPETRTY_IA_64_PRESERVE_GP set and
the linker can use it to detect the possible run-time failure and
issue a warning.
All such .o files? Meaning that you'll get Intel and HP and (...)
to change their object file generation?
Intel is ok with this. If HP wants to link against gcc generated
.o files safely with full optimization, the answer is yes.
Post by Richard Henderson
Anyway, for something this platform specific, you might as well use
an e_flags bit.
It is no binary compatible. Please keep in mind this only affects
.o files, executables and DSOs are ok. It doesn't make senses to
ask everyone to upgrade their whole IA64 system just to support
the ia64 psABI conforming .o files generated by the new gcc.

Here is the updated one to support --execstack/--noexecstack in gas.

H.J.
Richard Henderson
2003-06-06 05:32:41 UTC
Permalink
Post by H. J. Lu
Post by Richard Henderson
Anyway, for something this platform specific, you might as well use
an e_flags bit.
It is no binary compatible.
We're ALREADY talking about an ABI incompatibility. How does it make
more sense to hide this incompatibility in some random magic section?
Post by H. J. Lu
Please keep in mind this only affects .o files, executables and
DSOs are ok.
What has this got to do with anything?
Post by H. J. Lu
It doesn't make senses to
ask everyone to upgrade their whole IA64 system just to support
the ia64 psABI conforming .o files generated by the new gcc.
I see ZERO difference between your note section and using a bit
in the e_flags. Except that yours is more convoluted, and less
obvious that it is NOT advisory, unlike the execstack bit.

Please do not bother posting your patch again until the larger
community has come to some consensus on this point.


r~
H. J. Lu
2003-06-06 14:44:49 UTC
Permalink
Post by Richard Henderson
Post by H. J. Lu
Post by Richard Henderson
Anyway, for something this platform specific, you might as well use
an e_flags bit.
It is no binary compatible.
We're ALREADY talking about an ABI incompatibility. How does it make
more sense to hide this incompatibility in some random magic section?
Post by H. J. Lu
Please keep in mind this only affects .o files, executables and
DSOs are ok.
What has this got to do with anything?
Post by H. J. Lu
It doesn't make senses to
ask everyone to upgrade their whole IA64 system just to support
the ia64 psABI conforming .o files generated by the new gcc.
I see ZERO difference between your note section and using a bit
in the e_flags. Except that yours is more convoluted, and less
Can you make a proposal using a bit in the e_flags and describe its
impact on kernel, glibc, compiler and binutils? Also any change in
the e_flags will have go through the ia64 psABI.
Post by Richard Henderson
obvious that it is NOT advisory, unlike the execstack bit.
The problem only happens when

1. Mixing ABI conforming .o files with .o files containing external
funtions don't preserve GP. And
2. IPO with symbol visibility on the external funtions from non ABI
conforming .o files.

If one of them is not true, there is no problem. There are no problems
linking against shared libraries. My goal is to provide a way for
linker to detect possible run-time error with minimum changes required
for the rest of system. A bit in the note section seems a less
intrusive solution to me. But I am open to all suggestions.


H.J.
Jakub Jelinek
2003-06-06 07:41:59 UTC
Permalink
Post by H. J. Lu
Post by Richard Henderson
But it isn't safe without knowing if a .o file is ABI conforming or not.
Correct.
With my proposal, the .o files generated by ABI conforming
compiler will have the NT_GNU_PROPETRTY_IA_64_PRESERVE_GP set and
the linker can use it to detect the possible run-time failure and
issue a warning.
All such .o files? Meaning that you'll get Intel and HP and (...)
to change their object file generation?
Intel is ok with this. If HP wants to link against gcc generated
.o files safely with full optimization, the answer is yes.
Intel and HP compilers are going to emit .note.GNU-property section
(look at "GNU" in it)?

Jakub
H. J. Lu
2003-06-06 14:49:55 UTC
Permalink
Post by Jakub Jelinek
Post by H. J. Lu
Post by Richard Henderson
But it isn't safe without knowing if a .o file is ABI conforming or not.
Correct.
With my proposal, the .o files generated by ABI conforming
compiler will have the NT_GNU_PROPETRTY_IA_64_PRESERVE_GP set and
the linker can use it to detect the possible run-time failure and
issue a warning.
All such .o files? Meaning that you'll get Intel and HP and (...)
to change their object file generation?
Intel is ok with this. If HP wants to link against gcc generated
.o files safely with full optimization, the answer is yes.
Intel and HP compilers are going to emit .note.GNU-property section
(look at "GNU" in it)?
It is a GNU extension. If it is going to be the way to address this
issue, I hope everyone will have a open mind on the name of a note
section.


H.J.

Continue reading on narkive:
Loading...