| Message ID | 54445c79-cdb6-27a0-5704-d13e8f888f91@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Aug 14, 2017 at 9:34 AM, Florian Weimer <fweimer@redhat.com> wrote: > I compiled glibc on i386 with internal_function restored, with a special > GCC which encodes the regparm attribute value in the symbol name > (similar to what Windows does). This means that mismatches between > definition and use result in linker errors. > > This rediscovered the NSS mismatch already fixed, and another internal > mismatch related to mcount. This one is harmless; it's merely an > internal inconsistency introduced by the internal_function removal. > > After adjusting the Versions files to export the mangled names for > GLIBC_PRIVATE functions, all libraries link again and the public ABI > checks out, so I'm reasonably confident that we now have a consistent > build again. > > Is it possible to add a run-time test?
On 08/14/2017 07:09 PM, H.J. Lu wrote: > On Mon, Aug 14, 2017 at 9:34 AM, Florian Weimer <fweimer@redhat.com> wrote: >> I compiled glibc on i386 with internal_function restored, with a special >> GCC which encodes the regparm attribute value in the symbol name >> (similar to what Windows does). This means that mismatches between >> definition and use result in linker errors. >> >> This rediscovered the NSS mismatch already fixed, and another internal >> mismatch related to mcount. This one is harmless; it's merely an >> internal inconsistency introduced by the internal_function removal. >> >> After adjusting the Versions files to export the mangled names for >> GLIBC_PRIVATE functions, all libraries link again and the public ABI >> checks out, so I'm reasonably confident that we now have a consistent >> build again. > Is it possible to add a run-time test? I don't know. I expect a basic _mcount/profiling/gprof test to catch this. I don't think the calling convention is accidentally compatible. Some care is needed to avoid linking with system profiling libraries instead of the freshly build glibc. I don't know how to do that. I doubt that simply building and linking a test with -pg is sufficient. Thanks, Florian
On Mon, Aug 14, 2017 at 11:39 AM, Florian Weimer <fweimer@redhat.com> wrote: > On 08/14/2017 07:09 PM, H.J. Lu wrote: >> On Mon, Aug 14, 2017 at 9:34 AM, Florian Weimer <fweimer@redhat.com> wrote: >>> I compiled glibc on i386 with internal_function restored, with a special >>> GCC which encodes the regparm attribute value in the symbol name >>> (similar to what Windows does). This means that mismatches between >>> definition and use result in linker errors. >>> >>> This rediscovered the NSS mismatch already fixed, and another internal >>> mismatch related to mcount. This one is harmless; it's merely an >>> internal inconsistency introduced by the internal_function removal. >>> >>> After adjusting the Versions files to export the mangled names for >>> GLIBC_PRIVATE functions, all libraries link again and the public ABI >>> checks out, so I'm reasonably confident that we now have a consistent >>> build again. > >> Is it possible to add a run-time test? > > I don't know. I expect a basic _mcount/profiling/gprof test to catch > this. I don't think the calling convention is accidentally compatible. > Some care is needed to avoid linking with system profiling libraries > instead of the freshly build glibc. I don't know how to do that. I > doubt that simply building and linking a test with -pg is sufficient. > > Thanks, > Florian Here is a simple test on Fedora 26. [hjl@gnu-6 tmp]$ cat foo.c #include <stdio.h> void foo (void) { printf ("hello\n"); } int main () { foo (); return 0; } [hjl@gnu-6 tmp]$ gcc -c -pg foo.c [hjl@gnu-6 tmp]$ gcc -v -pg foo.o -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --with-multilib-list=m32,m64,mx32 --build=x86_64-redhat-linux Thread model: posix gcc version 7.1.1 20170709 (Red Hat 7.1.1-4) (GCC) COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/7/:/usr/libexec/gcc/x86_64-redhat-linux/7/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/7/:/usr/lib/gcc/x86_64-redhat-linux/ LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/7/:/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/7/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-pg' '-v' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/7/collect2 -plugin /usr/libexec/gcc/x86_64-redhat-linux/7/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper -plugin-opt=-fresolution=/tmp/cc4bjCNr.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/gcrt1.o /usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/7/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/7 -L/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/7/../../.. foo.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/7/crtend.o /usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crtn.o COLLECT_GCC_OPTIONS='-v' '-pg' '-v' '-mtune=generic' '-march=x86-64' [hjl@gnu-6 tmp]$ ./a.out hello [hjl@gnu-6 tmp]$ gprof a.out Flat profile: Each sample counts as 0.01 seconds. no time accumulated % cumulative self self total time seconds seconds calls Ts/call Ts/call name 0.00 0.00 0.00 1 0.00 0.00 foo % the percentage of the total running time of the time program used by this function. cumulative a running sum of the number of seconds accounted seconds for by this function and those listed above it. self the number of seconds accounted for by this seconds function alone. This is the major sort for this listing. calls the number of times this function was invoked, if this function is profiled, else blank. self the average number of milliseconds spent in this ms/call function per call, if this function is profiled, else blank. total the average number of milliseconds spent in this ms/call function and its descendents per call, if this function is profiled, else blank. name the name of the function. This is the minor sort for this listing. The index shows the location of the function in the gprof listing. If the index is in parenthesis it shows where it would appear in the gprof listing if it were to be printed. Copyright (C) 2012-2017 Free Software Foundation, Inc. Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. Call graph (explanation follows) granularity: each sample hit covers 2 byte(s) no time propagated index % time self children called name 0.00 0.00 1/1 main [7] [1] 0.0 0.00 0.00 1 foo [1] ----------------------------------------------- This table describes the call tree of the program, and was sorted by the total amount of time spent in each function and its children. Each entry in this table consists of several lines. The line with the index number at the left hand margin lists the current function. The lines above it list the functions that called this function, and the lines below it list the functions this one called. This line lists: index A unique number given to each element of the table. Index numbers are sorted numerically. The index number is printed next to every function name so it is easier to look up where the function is in the table. % time This is the percentage of the `total' time that was spent in this function and its children. Note that due to different viewpoints, functions excluded by options, etc, these numbers will NOT add up to 100%. self This is the total amount of time spent in this function. children This is the total amount of time propagated into this function by its children. called This is the number of times the function was called. If the function called itself recursively, the number only includes non-recursive calls, and is followed by a `+' and the number of recursive calls. name The name of the current function. The index number is printed after it. If the function is a member of a cycle, the cycle number is printed between the function's name and the index number. For the function's parents, the fields have the following meanings: self This is the amount of time that was propagated directly from the function into this parent. children This is the amount of time that was propagated from the function's children into this parent. called This is the number of times this parent called the function `/' the total number of times the function was called. Recursive calls to the function are not included in the number after the `/'. name This is the name of the parent. The parent's index number is printed after it. If the parent is a member of a cycle, the cycle number is printed between the name and the index number. If the parents of the function cannot be determined, the word `<spontaneous>' is printed in the `name' field, and all the other fields are blank. For the function's children, the fields have the following meanings: self This is the amount of time that was propagated directly from the child into the function. children This is the amount of time that was propagated from the child's children to the function. called This is the number of times the function called this child `/' the total number of times the child was called. Recursive calls by the child are not listed in the number after the `/'. name This is the name of the child. The child's index number is printed after it. If the child is a member of a cycle, the cycle number is printed between the name and the index number. If there are any cycles (circles) in the call graph, there is an entry for the cycle-as-a-whole. This entry shows who called the cycle (as parents) and the members of the cycle (as children.) The `+' recursive calls entry shows the number of function calls that were internal to the cycle, and the calls entry for each member shows, for that member, how many times it was called from other members of the cycle. Copyright (C) 2012-2017 Free Software Foundation, Inc. Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. Index by function name [1] foo [hjl@gnu-6 tmp]$ We don't profile gliibc.
On 08/14/2017 09:06 PM, H.J. Lu wrote: > Here is a simple test on Fedora 26. > > [hjl@gnu-6 tmp]$ cat foo.c > #include <stdio.h> > > void > foo (void) > { > printf ("hello\n"); > } > > int > main () > { > foo (); > return 0; > } > [hjl@gnu-6 tmp]$ gcc -c -pg foo.c Sure, but I'm worried about isolation from the host system. > We don't profile gliibc. See --enable-profile. -pg should pick up the profiling libc on systems where it is installed. We need to prevent that for the test. I think I have something which matches our requirements, but I still need to test it on a variety of architectures. Thanks, Florian
On Aug 15 2017, Florian Weimer <fweimer@redhat.com> wrote: > See --enable-profile. -pg should pick up the profiling libc on systems > where it is installed. -pg doesn't do that, -profile does. Andreas.
On 08/15/2017 01:55 PM, Andreas Schwab wrote: > On Aug 15 2017, Florian Weimer <fweimer@redhat.com> wrote: > >> See --enable-profile. -pg should pick up the profiling libc on systems >> where it is installed. > > -pg doesn't do that, -profile does. All the better. But I don't have to link with -pg after all, at least not on the targets I tested. Thanks, Florian
With the separate test patch I posted ([PATCH] Test for profiling support (_mcount/gprof)), is this now okay to commit? Thanks, Florian
On Tue, Aug 15, 2017 at 5:08 AM, Florian Weimer <fweimer@redhat.com> wrote: > With the separate test patch I posted ([PATCH] Test for profiling > support (_mcount/gprof)), is this now okay to commit? > Does the new test fail without the __mcount_internal patch?
On Aug 15 2017, Florian Weimer <fweimer@redhat.com> wrote: > On 08/15/2017 01:55 PM, Andreas Schwab wrote: >> On Aug 15 2017, Florian Weimer <fweimer@redhat.com> wrote: >> >>> See --enable-profile. -pg should pick up the profiling libc on systems >>> where it is installed. >> >> -pg doesn't do that, -profile does. > > All the better. But I don't have to link with -pg after all, at least > not on the targets I tested. You need -pg for the startup file. Andreas.
On 08/15/2017 02:22 PM, Andreas Schwab wrote: > On Aug 15 2017, Florian Weimer <fweimer@redhat.com> wrote: > >> On 08/15/2017 01:55 PM, Andreas Schwab wrote: >>> On Aug 15 2017, Florian Weimer <fweimer@redhat.com> wrote: >>> >>>> See --enable-profile. -pg should pick up the profiling libc on systems >>>> where it is installed. >>> >>> -pg doesn't do that, -profile does. >> >> All the better. But I don't have to link with -pg after all, at least >> not on the targets I tested. > > You need -pg for the startup file. -pg will use the system startup file, so we can't use that. We need to link against our own startup file, just like we do for non-profiled programs. Thanks, Florian
i386: Replace internal_function attribute for __mcount_internal __mcount_internal is called from assembler code. Use an explicit regparm attribute to pass both arguments in registers, to match what used to happen with internal_function before commit fbdc1e3e8de7f49e439b6e274d3e7e07da78416e (i386: Do not set internal_function). 2017-08-14 Florian Weimer <fweimer@redhat.com> * sysdeps/i386/machine-gmon.h (mcount_internal): Declare with regparm (2) instead of internal_function. (_MCOUNT_DECL): Adjust. diff --git a/sysdeps/i386/machine-gmon.h b/sysdeps/i386/machine-gmon.h index d5d8cdf7c6..3e90b8c0c7 100644 --- a/sysdeps/i386/machine-gmon.h +++ b/sysdeps/i386/machine-gmon.h @@ -29,10 +29,12 @@ /* We must not pollute the global namespace. */ #define mcount_internal __mcount_internal -extern void mcount_internal (u_long frompc, u_long selfpc) internal_function; +extern void mcount_internal (u_long frompc, u_long selfpc) + __attribute__ ((regparm (2))); -#define _MCOUNT_DECL(frompc, selfpc) \ -void internal_function mcount_internal (u_long frompc, u_long selfpc) +#define _MCOUNT_DECL(frompc, selfpc) \ + __attribute__ ((regparm (2))) \ +void mcount_internal (u_long frompc, u_long selfpc) /* Define MCOUNT as empty since we have the implementation in another