bugGprofng GUI - Bugs: bug #67165, Where is the "Resolve"...

 
 

bug #67165: Where is the "Resolve" button to associate a source file with a function?

Submitter:  Peter Kessler <peterkessler>
Submitted:  Thu 29 May 2025 12:10:10 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 05 Jun 2025 11:02:07 PM UTC, comment #4: 

My binutils-gdb repo is up to date through

    $ (cd binutils-gdb.git/ && git log)
    commit ec181e1710e37007a8d95c284609bfaa5868d086 (grafted, HEAD -> master, origin/master, origin/HEAD)
    Author: GDB Administrator <gdbadmin@sourceware.org>
    Date:   Thu Jun 5 00:00:31 2025 +0000

    Automatic date update in version.in

Is there a particular tag I should use, rather than pulling and building from the tip of the binutil-gdb repo?

Peter Kessler <peterkessler>
Thu 05 Jun 2025 10:53:35 PM UTC, comment #3: 

I said: "I rebuilt a JVM using gcc 10".  In fact, I was unable to use the JVM I built JVM with `gprofng display gui --jdkhome`.  I got an error window that said

    The J2SE[tm] 17 found at /home/pkessler/Work/OpenJDK/Clones/jdk-17-ga/jdk/build/linux-aarch64-server-release/images/jdk should not be usef by teh gprofng tools.  J2SE[tm] 1.8 is recommended.
    Use the -j option to specify a path to J2SE[tm] 1.8.

Instead of going all the way back to JDK 1.8, I used the JDK that come with my Fedora distro

    $ /usr/lib/jvm/java-20-openjdk-20.0.1.0.9-3.rolling.fc36.aarch64/bin/java -version
    openjdk version "20.0.1" 2023-04-18
    OpenJDK Runtime Environment (Red_Hat-20.0.1.0.9-1.rolling.fc36) (build 20.0.1+9)
    OpenJDK 64-Bit Server VM (Red_Hat-20.0.1.0.9-1.rolling.fc36) (build 20.0.1+9, mixed mode, sharing)

and that worked perfectly well.  I don't know what is wrong with my build of JDK-17 (That was the JDK I used to build `gprofng display gui`), but I am okay with using a more standard JVM to run `gprofng display gui`.

Peter Kessler <peterkessler>
Thu 05 Jun 2025 10:44:01 PM UTC, comment #2: 

I rebuilt everything (SPECint2017, binutils-gdb, a JVM) using gcc 10.3.1, and now `gprofng display` (both text and gui) knows how to find my source files and line numbers.

I am pretty sure this is with the dwarf version produced by my gcc 12 compiler.  How do find out what dwarf version is being used?

What is the highest (or best :-) version of dwarf that gprofng supports?  I probably can not downgrade to using gcc 10 for everything I want to profile, but I might be able to recompile with -gdwarf-4 or something.

Peter Kessler <peterkessler>
Wed 04 Jun 2025 12:06:08 AM UTC, comment #1: 

I am compiling on aarch64 with

    gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)

I see from https://sourceware.org/bugzilla/show_bug.cgi?id=30195 that the version of gcc might matter.  I will try recompiling with an earlier gcc.

Peter Kessler <peterkessler>
Thu 29 May 2025 12:10:10 AM UTC, original submission:  

https://www.gnu.org/software/gprofng-gui/manual/gprofng-gui.html#Source-1 refers to a "Resolve" button that should let me point to the source for a function.  I can not find that button.

I have an experiment profiling SPECint2017, and the function profile says the hot method for 520.omnetpp_r is cMessageHeap::removeFirst().  But when I go to the Source or Source/Disassembly view it says

    Source file `(unknown)' not readable. 

There is no "Resolve" button on offer.

I can search by hand to find the function in

    $ find ./spec2017 -name "*.cc" -print | xargs grep '^cMessage \*cMessageHeap::removeFirst\(\)'
    ./spec2017/benchspec/CPU/520.omnetpp_r/src/simulator/cmessageheap.cc:cMessage *cMessageHeap::removeFirst()
    ./spec2017/benchspec/CPU/520.omnetpp_r/build/build_base_gcc12_for_gprofng-64.0000/simulator/cmessageheap.cc:cMessage *cMessageHeap::removeFirst()

(With duplicate definitions because of the way SPECint2017 copies source files around.  "gcc12_for_gprofng" is the name of my SPECint2017 config file.  If you don't know SPECint2017, I can try to help, but I am just using 520.omnetpp_r as an example experiment for a gprofng demo I would like to give.)

I can not figure out how to use the Tools / Settings / Search Path window to add anything that would resolve the file name for the unknown file.  I have tried setting my Search Path to

    $expts
    .
    ./spec2017/benchspec/CPU/520.omnetpp_r/build/build_base_gcc12_for_gprofng-64.0000/simulator
    ./spec2017/benchspec/CPU/520.omnetpp_r/src/simulator/cmessageheap.cc
    ./spec2017/benchspec/CPU/520.omnetpp_r/build/build_base_gcc12_for_gprofng-64.0000/simulator/cmessageheap.cc

but gprofng is unable to find the function.  I have compiled everything with -g.

Thanks for any suggestions you have.

            ... peter

Peter Kessler <peterkessler>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by peterkessler (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code