This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

internal_function symbols part of the public ABI

I've just realized that the internal_function removal breaks ABI on i386.

Commit 384ca551743318bd9c9e24a496d6397f2e3f2a49 from 2007 added this to

+#ifndef NO_COMPAT
+internal_function attribute_compat_text_section
+DB_COMPAT_FCT (service_user **ni, const char *fct_name, void **fctp)
+  return DB_LOOKUP_FCT (ni, fct_name, NULL, fctp);

That is, it adds a pseudo-compat function with an internal_function
attribute.  The function it was supposed to replace did not have the

 extern int DB_LOOKUP_FCT (service_user **ni, const char *fct_name,
-			  void **fctp) internal_function;
+			  const char *fct2_name, void **fctp)
+  internal_function;

As far as I can tell, this changed the following functions in the public


What shall we do here?  The function is impossible to call from
CET-protected binaries because %ecx is clobbered (on the first call) by
the dynamic resolver trampoline.

The 2007 commit radically changed the calling convention, so it's safe
to assume that there were no active users on i386 at the time because
they would have run into crashes.  Today, it's still difficult to call
these functions because it is hard to write a correct prototype.

Can we remove the functions completely?  Should we add a stub which
always returns an error?  The stub would be compatible with both ABIs
because the function takes three arguments and regparm (3) means that
there are no on-stack arguments, so stdcall vs no stdcall does not
matter (which changes whether the caller or callee pops the arguments
from the stack).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]