diff mbox

powerpc: Remove unintended __longjmp export

Message ID 771d4c34-534f-228a-3041-2610145c8baa@redhat.com
State Accepted
Commit 76388b236a7089f6ee5dc0a566caa518132f16bd
Headers show

Commit Message

Florian Weimer Nov. 22, 2016, 4:43 p.m. UTC
Due to an accident, we export __longjmp under a public symbol version 
for the powerpc32/fpu configuration.

__longjmp is declared as hidden for internal use.  This means that any 
reference to this symbol (of which there aren't any right now in 
libc.so) will cause the symbol to turn unexported.  The reason is that 
the linker does not distinguish between hidden definitions and 
references.  GCC emits a .hidden directive in the __longjmp-referencing 
translation unit, and this kills the .symver-based export.

I propose the removal of the __longjmp export as the simplest fix. 
__longjmp is in the implementation namespace and is not used in a public 
header.  As a result, nothing out there should reference it.

If this is not acceptable, I'll come up with different approach to 
address this.  But I prefer to address this issue in this way.

Tested on a powerpc32/fpu configuration with no regressions.

Florian

Comments

Mike Frysinger Nov. 27, 2016, 6:45 a.m. UTC | #1
On 22 Nov 2016 17:43, Florian Weimer wrote:
> Due to an accident, we export __longjmp under a public symbol version 

> for the powerpc32/fpu configuration.

> 

> __longjmp is declared as hidden for internal use.  This means that any 

> reference to this symbol (of which there aren't any right now in 

> libc.so) will cause the symbol to turn unexported.  The reason is that 

> the linker does not distinguish between hidden definitions and 

> references.  GCC emits a .hidden directive in the __longjmp-referencing 

> translation unit, and this kills the .symver-based export.

> 

> I propose the removal of the __longjmp export as the simplest fix. 

> __longjmp is in the implementation namespace and is not used in a public 

> header.  As a result, nothing out there should reference it.

> 

> If this is not acceptable, I'll come up with different approach to 

> address this.  But I prefer to address this issue in this way.

> 

> Tested on a powerpc32/fpu configuration with no regressions.


makes sense to me.  not sure how any package would end up with a reference
to this symbol in their binaries.
-mike
Florian Weimer Nov. 27, 2016, 1:59 p.m. UTC | #2
On 11/27/2016 07:45 AM, Mike Frysinger wrote:
> On 22 Nov 2016 17:43, Florian Weimer wrote:

>> Due to an accident, we export __longjmp under a public symbol version

>> for the powerpc32/fpu configuration.

>>

>> __longjmp is declared as hidden for internal use.  This means that any

>> reference to this symbol (of which there aren't any right now in

>> libc.so) will cause the symbol to turn unexported.  The reason is that

>> the linker does not distinguish between hidden definitions and

>> references.  GCC emits a .hidden directive in the __longjmp-referencing

>> translation unit, and this kills the .symver-based export.

>>

>> I propose the removal of the __longjmp export as the simplest fix.

>> __longjmp is in the implementation namespace and is not used in a public

>> header.  As a result, nothing out there should reference it.

>>

>> If this is not acceptable, I'll come up with different approach to

>> address this.  But I prefer to address this issue in this way.

>>

>> Tested on a powerpc32/fpu configuration with no regressions.

>

> makes sense to me.  not sure how any package would end up with a reference

> to this symbol in their binaries.


Thanks.  I'll plan to commit this next week, and also the companion 
patch to add a missing hidden symbol.

Steven and Tulio, in case you want to comment, these patches are here:

https://sourceware.org/ml/libc-alpha/2016-11/msg00794.html
https://sourceware.org/ml/libc-alpha/2016-11/msg00798.html

Thanks,
Florian
Tulio Magno Quites Machado Filho Nov. 28, 2016, 1:04 p.m. UTC | #3
Florian Weimer <fweimer@redhat.com> writes:

> Due to an accident, we export __longjmp under a public symbol version 

> for the powerpc32/fpu configuration.

>

> __longjmp is declared as hidden for internal use.  This means that any 

> reference to this symbol (of which there aren't any right now in 

> libc.so) will cause the symbol to turn unexported.  The reason is that 

> the linker does not distinguish between hidden definitions and 

> references.  GCC emits a .hidden directive in the __longjmp-referencing 

> translation unit, and this kills the .symver-based export.

>

> I propose the removal of the __longjmp export as the simplest fix. 

> __longjmp is in the implementation namespace and is not used in a public 

> header.  As a result, nothing out there should reference it.

>

> If this is not acceptable, I'll come up with different approach to 

> address this.  But I prefer to address this issue in this way.

>

> Tested on a powerpc32/fpu configuration with no regressions.


Makes sense to me too.

-- 
Tulio Magno
Florian Weimer Nov. 29, 2016, 10:12 a.m. UTC | #4
On 11/28/2016 02:04 PM, Tulio Magno Quites Machado Filho wrote:
> Florian Weimer <fweimer@redhat.com> writes:

>

>> Due to an accident, we export __longjmp under a public symbol version

>> for the powerpc32/fpu configuration.

>>

>> __longjmp is declared as hidden for internal use.  This means that any

>> reference to this symbol (of which there aren't any right now in

>> libc.so) will cause the symbol to turn unexported.  The reason is that

>> the linker does not distinguish between hidden definitions and

>> references.  GCC emits a .hidden directive in the __longjmp-referencing

>> translation unit, and this kills the .symver-based export.

>>

>> I propose the removal of the __longjmp export as the simplest fix.

>> __longjmp is in the implementation namespace and is not used in a public

>> header.  As a result, nothing out there should reference it.

>>

>> If this is not acceptable, I'll come up with different approach to

>> address this.  But I prefer to address this issue in this way.

>>

>> Tested on a powerpc32/fpu configuration with no regressions.

>

> Makes sense to me too.


Thanks, I have committed both patches.

Florian
diff mbox

Patch

powerpc: Remove unintended __longjmp symbol from ABI

2016-11-22  Florian Weimer  <fweimer@redhat.com>

	* sysdeps/powerpc/powerpc32/fpu/__longjmp.S (__longjmp): Remove
	version and turn into strong alias.  Remove compat symbol.

	* sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist
	(__longjmp): Remove.

diff --git a/sysdeps/powerpc/powerpc32/fpu/__longjmp.S b/sysdeps/powerpc/powerpc32/fpu/__longjmp.S
index 529e095..c233b88 100644
--- a/sysdeps/powerpc/powerpc32/fpu/__longjmp.S
+++ b/sysdeps/powerpc/powerpc32/fpu/__longjmp.S
@@ -26,15 +26,13 @@ 
 # include "__longjmp-common.S"
 
 #else /* IS_IN (libc) */
-/* Build a versioned object for libc.  */
-versioned_symbol (libc, __vmx__longjmp, __longjmp, GLIBC_2_3_4);
+strong_alias (__vmx__longjmp, __longjmp)
 # define __longjmp_symbol  __vmx__longjmp
 # include "__longjmp-common.S"
 
 # if defined SHARED && SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_3_4)
 #  define __NO_VMX__
 #  undef JB_SIZE
-compat_symbol (libc, __novmx__longjmp, __longjmp, GLIBC_2_0);
 #  undef __longjmp_symbol
 #  define __longjmp_symbol  __novmx__longjmp
 #  include "__longjmp-common.S"
diff --git a/sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist b/sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist
index 4b0cde8..4ba3146 100644
--- a/sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist
+++ b/sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist
@@ -2112,7 +2112,6 @@  GLIBC_2.3.4 GLIBC_2.3.4 A
 GLIBC_2.3.4 __chk_fail F
 GLIBC_2.3.4 __fprintf_chk F
 GLIBC_2.3.4 __gets_chk F
-GLIBC_2.3.4 __longjmp F
 GLIBC_2.3.4 __memcpy_chk F
 GLIBC_2.3.4 __memmove_chk F
 GLIBC_2.3.4 __mempcpy_chk F