This is the mail archive of the libc-alpha@sourceware.org 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]

Re: [PATCH 2.25] powerpc: Avoid calling strncmp via PLT on GCC 7


On Mon, 2017-01-16 at 23:58 +0100, Florian Weimer wrote:
> * Joseph Myers:
> 
> > On Mon, 16 Jan 2017, Aaron Sawdey wrote:
> > 
> > > Tulio,
> > >   I'll be posting an updated version of that patch shortly that
> > > addresses the issues you were seeing. However it adds builtin
> > > expansion
> > > of both strncmp and strcmp so I think your patch needs to add
> > > both to
> > > powerpc/symbol-hacks.h. Here is what I get from check-localplt
> > > with
> > > gcc7 plus this patch:
> > > 
> > > cat /home/sawdey/src/glibc/build/elf/check-localplt.out
> > > Extra PLT reference: libc.so: strcmp
> > > Extra PLT reference: libc.so: strncmp
> > 
> > On further consideration: I don't think addressing this in GCC
> > should be 
> > hard, can't you just look up something like DECL_ASSEMBLER_NAME 
> > (builtin_decl_explicit (BUILT_IN_STRNCMP)) or similar and use that
> > instead 
> > of hardcoded strncmp when generating code?

I really don't see how I'm supposed to discover that I need to use
__GI_strncmp in this instance. For example when I compile
misc/getttyent.c with this code in the expansion function:

printf("ASM: %s\n", IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
(builtin_decl_explicit (BUILT_IN_STRNCMP))));

I get "ASM: strncmp". This is one of the places that is producing a plt
call to strncmp. The preprocessed source has this declaration for
strncmp:

extern int strncmp (const char *__s1, const char *__s2, size_t __n)
     __attribute__ ((__nothrow__ )) __attribute__ ((__pure__)) ;

I don't really see how gcc is suppose to be able to find this
__GI_strncmp name here.

> 
> Right.  I forgot that GCC does exactly this for other builtins.  We
> even have a configure check:
> 
> AC_CACHE_CHECK(for redirection of built-in functions,
> libc_cv_gcc_builtin_redirection, [dnl
> cat > conftest.c <<\EOF
> extern char *strstr (const char *, const char *) __asm ("my_strstr");
> char *foo (const char *a, const char *b)
> {
>   return __builtin_strstr (a, b);
> }
> EOF
> dnl
> if AC_TRY_COMMAND([${CC-cc} -O3 -S conftest.c -o - | fgrep
> "my_strstr" > /dev/null]);
> then
>   libc_cv_gcc_builtin_redirection=yes
> else
>   libc_cv_gcc_builtin_redirection=no
> fi
> rm -f conftest* ])
> if test "$libc_cv_gcc_builtin_redirection" = no; then
>   AC_MSG_ERROR([support for the symbol redirection needed])
> fi

This test case does work for strncmp:

extern int strncmp (const char *, const char *, unsigned long) __asm
("my_strncmp");
int foo (const char *a, const char *b)
{
  return __builtin_strncmp (a, b, 10);
}

In this case I get "ASM: *my_strncmp" from the debug code in the
compiler when it expands strncmp. But the preprocessed code for
getttyent.c does not have an __asm directive to tell me this.

> 
> So you are right that this should be fixed in GCC.

I'm starting to believe this is possible but I think the glibc code
doesn't give all the information needed for this yet. Also I can't
quite see why symbol-hacks.h redefinitions of memcmp/memmov/memset is
needed unless the compiler is not looking up this asm name elsewhere.

  Aaron

-- 
Aaron Sawdey, Ph.D.  acsawdey@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC Toolchain


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