[PATCH] gprof: Copy a simple test from glibc

Tue Apr 1 07:37:19 GMT 2025

On 31.03.2025 18:37, H.J. Lu wrote:
> On Mon, Mar 31, 2025 at 9:35 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> On Mon, Mar 31, 2025 at 9:30 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>
>>> On Mon, Mar 31, 2025 at 9:21 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>
>>>> On Mon, Mar 31, 2025 at 9:18 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>
>>>>> On Mon, Mar 31, 2025 at 9:00 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 31.03.2025 17:02, H.J. Lu wrote:
>>>>>>> On Mon, Mar 31, 2025 at 12:56 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> On 28.03.2025 16:23, H.J. Lu wrote:
>>>>>>>>> On Fri, Mar 28, 2025 at 1:46 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 07.03.2025 00:00, H.J. Lu wrote:
>>>>>>>>>>> Copy a simple gprof test from glibc to test the basic gprof functionality.
>>>>>>>>>>>
>>>>>>>>>>> PR gprof/32764
>>>>>>>>>>> * Makefile.am (SUBDIRS): Add testsuite
>>>>>>>>>>> * configure.ac (AC_CONFIG_FILES): Removed.
>>>>>>>>>>> (AC_OUTPUT): Add Makefile testsuite/Makefile
>>>>>>>>>>> po/Makefile.in:po/Make-in.
>>>>>>>>>>> (AM_CONDITIONAL): Add NATIVE.
>>>>>>>>>>> * Makefile.in: Regenerated.
>>>>>>>>>>> * configure: Likewise.
>>>>>>>>>>> * testsuite/Makefile.am: New file.
>>>>>>>>>>> * testsuite/tst-gmon-gprof.sh: Likewise.
>>>>>>>>>>> * testsuite/tst-gmon.c: Likewise.
>>>>>>>>>>> * testsuite/Makefile.in: Generated.
>>>>>>>>>>
>>>>>>>>>> This and the other new test fail for me on both x86-64 systems I tried - the
>>>>>>>>>> f3 line isn't present in gprof output. I fear I don't have the time to
>>>>>>>>>> investigate from grounds up. IOW either I need pointers that make
>>>>>>>>>> investigation reasonably easy, or I'll propose to disable the tests again
>>>>>>>>>> until this is sorted. The one thing I did check is that the object file has
>>>>>>>>>> all the supposed calls to mcount(). If it matters, one system is using gcc5,
>>>>>>>>>> the other gcc7.
>>>>>>>>>
>>>>>>>>> These tests work for me with gcc 5.4.1 and 7.4.1.  Please try
>>>>>>>>>
>>>>>>>>> https://sourceware.org/pipermail/binutils/2025-March/140257.html
>>>>>>>>
>>>>>>>> Well, tst-gmon.o clearly had debug info (incl .debug_line) already. So no
>>>>>>>> difference there. Ftaod tst-gmon similarly has debug info (incl .debug_line).
>>>>>>>> Must be something else, possibly in gprof itself.
>>>>>>>
>>>>>>> Can you send me your gprof build directory, including tests?
>>>>>>
>>>>>> This is the state of the directory after the failure (plus the disassembly of
>>>>>> the object file that I used to do the minimal checking that I mentioned). If
>>>>>> by "including tests" you mean yet something else, please be specific.
>>>>>>
>>>>>
>>>>> Please send me the whole gprof build directory,  like
>>>>>
>>>>> aarch64.o       cg_print.o     fsf_callg_bl.c  hertz.o        source.o
>>>>> alpha.o         config.cache   fsf_callg_bl.o  hist.o         sparc.o
>>>>> basic_blocks.o  config.log     gconfig.h       i386.o         stamp-h1
>>>>> bsd_callg_bl.c  config.status  gmon_io.o       libtool        sym_ids.o
>>>>> bsd_callg_bl.o  config.texi    gprof           Makefile       symtab.o
>>>>> call_graph.o    corefile.o     gprof.1         mips.o         testsuite
>>>>> cg_arcs.o       flat_bl.c      gprof.info      po             utils.o
>>>>> cg_dfn.o        flat_bl.o      gprof.o         search_list.o  vax.o
>>>>>
>>>>
>>>> You used GCC: (SUSE Linux) 4.8.5, not gcc5 nor gcc7 as
>>>> you said earlier.

Oh, I'm sorry. I'm in need of forcing use of the secondary compiler there
for an increasing number of projects, so I keep forgetting that the main
compiler there is older. It is gcc7 on the other system. Yet from further
responses of yours I conclude this doesn't matter anymore.

>>> GCC 4.8.5 works for me.  My tst-gmon.o has R_X86_64_PLT32 and
>>> yours has R_X86_64_PC32.  I don't think it matters here.  Which glibc
>>> do you have?  It may be a glibc bug.
>>>
>>
>> No need for the whole gprof directory.  I used your tst-gmon.o with
>> GCC 4.8.5.  It works correctly.  It looks like your glibc is buggy.
> 
> Please verify if this glibc bug:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=28153
> 
> is the cause.

Well, yes, main() is before _start() in the executables on both systems.
The older system has glibc 2.22, the newer glibc 2.26. And no, I do not
think I should be upgrading the distros there. As said on earlier
occasions, testcases ought to work independent of the underlying
platform, or be disabled if they can't be made work in older
environments.

I couldn't find a command line option to pass to gcc to avoid use of
.text.startup / .text.startup.main. Adding
__attribute__((section(".text.main"))) may help, but may not be portable
enough.

Jan