[Bug gprofng/32110] gprofng segfaults on parsing DWARF of clang++ 18.1.3 produced binary

https://sourceware.org/bugzilla/show_bug.cgi?id=32110 --- Comment #9 from Vladimir Mezentsev --- This is an error when gprofng reads Dwarf-5. The easiest test to reproduce the problem: % gprofng display src -func graal/sdk/mxbuild/linux-amd64/PYTHON_JAVA_STANDALONE_SVM_JAVA24/graalpy-community-2

[Bug gprofng/32207] [collect app] Error in parsing the -O option

https://sourceware.org/bugzilla/show_bug.cgi?id=32207 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug gprofng/32096] UBSAN issues in gprofng

https://sourceware.org/bugzilla/show_bug.cgi?id=32096 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNE

[Bug gprofng/32092] gprofng testsuite fails with -flto (ERROR: comparison of results in synprog failed)

https://sourceware.org/bugzilla/show_bug.cgi?id=32092 Bug 32092 depends on bug 32096, which changed state. Bug 32096 Summary: UBSAN issues in gprofng https://sourceware.org/bugzilla/show_bug.cgi?id=32096 What|Removed |Added --

[Bug gprofng/32200] gprofng is not compatible with the Phytium (CPU) platform.

https://sourceware.org/bugzilla/show_bug.cgi?id=32200 Vladimir Mezentsev changed: What|Removed |Added Ever confirmed|0 |1 Assignee|vladimir.me

[Bug gprofng/32096] UBSAN issues in gprofng

https://sourceware.org/bugzilla/show_bug.cgi?id=32096 --- Comment #6 from Vladimir Mezentsev --- I just sent fixes in libcollector/unwind.c and src/CallStack.cc for review. This fixes UBSAN runtime errors such as: - load of misaligned address 0x623e5a670173 for type 'int', which requires 4 byte

[Bug gprofng/32110] gprofng segfaults on parsing DWARF of clang++ 18.1.3 produced binary

https://sourceware.org/bugzilla/show_bug.cgi?id=32110 --- Comment #7 from Vladimir Mezentsev --- I cannot build. Looks like I need some additional installation: % ../../mx/mx --env ce-python build --dep PYTHON_JAVA_STANDALONE_SVM_JAVA24 <...> Traceback (most recent call last): File "<...>/gra

[Bug gprofng/32096] UBSAN issues in gprofng

https://sourceware.org/bugzilla/show_bug.cgi?id=32096 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Vla

[Bug gprofng/32097] Warnings when building gprofng with Clang

https://sourceware.org/bugzilla/show_bug.cgi?id=32097 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNE

[Bug gprofng/32110] gprofng segfaults on parsing DWARF of clang++ 18.1.3 produced binary

https://sourceware.org/bugzilla/show_bug.cgi?id=32110 --- Comment #5 from Vladimir Mezentsev --- The good news is that I didn't commit this fix. The bad news is that the fix was wrong. I see a regression in our testing. Looks like memory corruption in Dwarf reader. I'll try to reproduce the prob

[Bug gprofng/29477] Build failure on musl: collector_module.h:78:13: error: duplicate member ‘pwrite’

https://sourceware.org/bugzilla/show_bug.cgi?id=29477 Vladimir Mezentsev changed: What|Removed |Added Status|WAITING |SUSPENDED --- Comment #10 from V

[Bug gprofng/29593] error: '__u64' undeclared (first use in this function) for aarch64-linux-musl host

https://sourceware.org/bugzilla/show_bug.cgi?id=29593 Vladimir Mezentsev changed: What|Removed |Added Status|ASSIGNED|SUSPENDED --- Comment #6 from Vl

[Bug gprofng/30779] support gprofng on musl

https://sourceware.org/bugzilla/show_bug.cgi?id=30779 Vladimir Mezentsev changed: What|Removed |Added Summary|gprofng: fails to build |support gprofng on musl

[Bug gprofng/32110] gprofng segfaults on parsing DWARF of clang++ 18.1.3 produced binary

https://sourceware.org/bugzilla/show_bug.cgi?id=32110 Vladimir Mezentsev changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug gprofng/32110] gprofng segfaults on parsing DWARF of clang++ 18.1.3 produced binary

https://sourceware.org/bugzilla/show_bug.cgi?id=32110 --- Comment #4 from Vladimir Mezentsev --- Tim, please push your fix to the master branch. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gprofng/32092] gprofng testsuite fails with -flto (ERROR: comparison of results in synprog failed)

https://sourceware.org/bugzilla/show_bug.cgi?id=32092 --- Comment #8 from Vladimir Mezentsev --- I can reproduce the problem. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gprofng/32085] Source file not recognized for gcc 11.4.0-compiled code

https://sourceware.org/bugzilla/show_bug.cgi?id=32085 --- Comment #4 from Vladimir Mezentsev --- >From DWARF standard: 7.5 Format of Debugging Information For each compilation unit compiled with a DWARF producer, a contribution is made to the .debug_info section of the object file. Each such co

[Bug gprofng/32085] Source file not recognized for gcc 11.4.0-compiled code

https://sourceware.org/bugzilla/show_bug.cgi?id=32085 --- Comment #3 from Vladimir Mezentsev --- Created attachment 15679 --> https://sourceware.org/bugzilla/attachment.cgi?id=15679&action=edit synprog -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gprofng/30779] gprofng: fails to build with musl-1.2.4 (gprofng/src/Data_window.h:56:3: error: 'off64_t' does not name a type; did you mean 'off_t'?)

https://sourceware.org/bugzilla/show_bug.cgi?id=30779 --- Comment #30 from Vladimir Mezentsev --- Let's disable the gprofng build for musl. I don't have a musl machine to test this fix: % git diff diff --git a/configure b/configure index 7823f2c3784..93d286bb3b7 100755 --- a/configure +++ b/conf

[Bug gprofng/32088] New language support: Python

https://sourceware.org/bugzilla/show_bug.cgi?id=32088 --- Comment #1 from Vladimir Mezentsev --- The PEP669 mechanism is very similar to the one we use for Java profiling. We can try using PEP669 to profile Python applications. -- You are receiving this mail because: You are on the CC list for

[Bug gprofng/32097] Warnings when building gprofng with Clang

https://sourceware.org/bugzilla/show_bug.cgi?id=32097 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Vla

[Bug gprofng/32092] gprofng testsuite fails with -flto (ERROR: comparison of results in synprog failed)

https://sourceware.org/bugzilla/show_bug.cgi?id=32092 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from Vla

[Bug gprofng/31169] [display text] Source code locations can not be found in a C++ application

https://sourceware.org/bugzilla/show_bug.cgi?id=31169 Vladimir Mezentsev changed: What|Removed |Added See Also||https://sourceware.org/bugz

[Bug gprofng/32085] Source file not recognized for gcc 11.4.0-compiled code

https://sourceware.org/bugzilla/show_bug.cgi?id=32085 Vladimir Mezentsev changed: What|Removed |Added Last reconfirmed||2024-08-15 Ever confirmed|0

[Bug gprofng/32018] Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6

https://sourceware.org/bugzilla/show_bug.cgi?id=32018 Vladimir Mezentsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug gprofng/32018] Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6

https://sourceware.org/bugzilla/show_bug.cgi?id=32018 --- Comment #12 from Vladimir Mezentsev --- Could you try this fix on CentOS: % diff --git a/gprofng/libcollector/hwprofile.c b/gprofng/libcollector/hwprofile.c index cfe0d84dc1e..3b7f4840aa0 100644 --- a/gprofng/libcollector/hwprofile.c +++

[Bug gprofng/32018] Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6

https://sourceware.org/bugzilla/show_bug.cgi?id=32018 --- Comment #9 from Vladimir Mezentsev --- If there is a similar problem on CentOS 7, could you please attach this output: % grep -n -s -w strchr /usr/include/*/* It looks like strchr is redefined as a macro. -- You are receiving this mai

[Bug gprofng/32018] Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6

https://sourceware.org/bugzilla/show_bug.cgi?id=32018 --- Comment #7 from Vladimir Mezentsev --- Why do you use CentOS 6 ? I see this: Release Release dateEnd of life CentOS 7July 7, 2014June 30, 2024 CentOS 6July 10, 2011 November 30, 2020 EOF of CentOS 6 was in 2020.

[Bug gprofng/32018] Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6

https://sourceware.org/bugzilla/show_bug.cgi?id=32018 --- Comment #6 from Vladimir Mezentsev --- > In file included from /usr/include/string.h:637, > from ../../../gprofng/libcollector/../common/hwcdrv.h:37, > from ../../../gprofng/libcollector/hwprofile.c:35: >

[Bug gprofng/32018] Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6

https://sourceware.org/bugzilla/show_bug.cgi?id=32018 --- Comment #4 from Vladimir Mezentsev --- What is in your /usr/include/string.h in lines around 637 ? Could you please attach this output: cat -n /usr/include/string.h | sed -n "625,650 p" -- You are receiving this mail because: You are

[Bug gprofng/32018] Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6

https://sourceware.org/bugzilla/show_bug.cgi?id=32018 Vladimir Mezentsev changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0

[Bug gprofng/31123] improvements to hardware event implementation

https://sourceware.org/bugzilla/show_bug.cgi?id=31123 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNE

[Bug gprofng/30779] gprofng: fails to build with musl-1.2.4 (gprofng/src/Data_window.h:56:3: error: 'off64_t' does not name a type; did you mean 'off_t'?)

https://sourceware.org/bugzilla/show_bug.cgi?id=30779 --- Comment #28 from Vladimir Mezentsev --- >> Created attachment 15609 [details] >> finally get this work The 2.43 release will be on Sunday 14th July. If your fix works with MUSL_LIBC, could you push your fixes to sourceware.org/git/binuti

[Bug gprofng/30779] gprofng: fails to build with musl-1.2.4 (gprofng/src/Data_window.h:56:3: error: 'off64_t' does not name a type; did you mean 'off_t'?)

https://sourceware.org/bugzilla/show_bug.cgi?id=30779 --- Comment #27 from Vladimir Mezentsev --- >> i should use wchar.h instead not stdio.h since stdio also defines some 64 >> file ops Can you set _MUSL_LIBC in gprofng/configure.ac instead of gp-defs.h. >> it does not really work out. a

[Bug binutils/30281] error: multiple definition of `pwrite@GLIBC_2.2' with LTO and symver attribute

https://sourceware.org/bugzilla/show_bug.cgi?id=30281 --- Comment #14 from Vladimir Mezentsev --- I think H.J. Lu's fixes are in 2.42. Try downloading version 2.42 or building the latest version of the binutils-gdb repository. -- You are receiving this mail because: You are on the CC list for

[Bug binutils/30281] error: multiple definition of `pwrite@GLIBC_2.2' with LTO and symver attribute

https://sourceware.org/bugzilla/show_bug.cgi?id=30281 --- Comment #12 from Vladimir Mezentsev --- It looks like your ld is old. See H.J. Lu's comments/fixes for ld above. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gprofng/31460] heap tracing causes infinite recursion on calloc with multi-threaded applications

https://sourceware.org/bugzilla/show_bug.cgi?id=31460 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNE

[Bug gprofng/31460] heap tracing causes infinite recursion on calloc with multi-threaded applications

https://sourceware.org/bugzilla/show_bug.cgi?id=31460 --- Comment #7 from Vladimir Mezentsev --- Created attachment 15433 --> https://sourceware.org/bugzilla/attachment.cgi?id=15433&action=edit proposed patch -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gprofng/31460] heap tracing causes infinite recursion on calloc with multi-threaded applications

https://sourceware.org/bugzilla/show_bug.cgi?id=31460 --- Comment #5 from Vladimir Mezentsev --- The problem is: We use pthread_getspecific() and pthread_setspecific() to access thread local memory. We use this memory to check that our interposed functions (like malloc, calloc or free) don't hav

[Bug gprofng/31460] heap tracing causes infinite recursion on calloc with multi-threaded applications

https://sourceware.org/bugzilla/show_bug.cgi?id=31460 --- Comment #4 from Vladimir Mezentsev --- It looks like the bug is in gprofng/libcollector/heaptrace.c. I see that init_heap_intf() is not thread safe. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gprofng/31460] heap tracing causes infinite recursion on calloc with multi-threaded applications

https://sourceware.org/bugzilla/show_bug.cgi?id=31460 --- Comment #1 from Vladimir Mezentsev --- I cannot reproduce the problem on OL8 with libpthread-2.28. It looks like calloc() is called in ./nptl/pthread_setspecific.c:69 But this calloc() must be from libc, not from the user application.

[Bug gprofng/31460] heap tracing causes infinite recursion on calloc with multi-threaded applications

https://sourceware.org/bugzilla/show_bug.cgi?id=31460 Vladimir Mezentsev changed: What|Removed |Added Last reconfirmed||2024-03-19 Ever confirmed|0

[Bug gprofng/31459] need a way to suppress the stderr message

https://sourceware.org/bugzilla/show_bug.cgi?id=31459 Vladimir Mezentsev changed: What|Removed |Added Last reconfirmed||2024-03-10 Status|UN

[Bug gprofng/31109] gprofng not built and installed in a combined binutils+gcc build

https://sourceware.org/bugzilla/show_bug.cgi?id=31109 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug gprofng/30808] gprofng tests failed

https://sourceware.org/bugzilla/show_bug.cgi?id=30808 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENE

[Bug gprofng/30889] can't compile without large file support

https://sourceware.org/bugzilla/show_bug.cgi?id=30889 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNE

[Bug gprofng/31252] gprofng causes testsuite parallel jobs fail (again)

https://sourceware.org/bugzilla/show_bug.cgi?id=31252 Vladimir Mezentsev changed: What|Removed |Added Last reconfirmed||2024-01-19 Ever confirmed|0

[Bug gprofng/30808] gprofng tests failed

https://sourceware.org/bugzilla/show_bug.cgi?id=30808 --- Comment #5 from Vladimir Mezentsev --- On 1/18/24 10:33, hjl.tools at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=30808 > > H.J. Lu changed: > > What|Removed |Added > ---

[Bug gprofng/30889] can't compile without large file support

https://sourceware.org/bugzilla/show_bug.cgi?id=30889 Vladimir Mezentsev changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug gprofng/29593] error: '__u64' undeclared (first use in this function) for aarch64-linux-musl host

https://sourceware.org/bugzilla/show_bug.cgi?id=29593 --- Comment #4 from Vladimir Mezentsev --- Has the build problem been fixed in your environment? -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gprofng/30779] gprofng: fails to build with musl-1.2.4 (gprofng/src/Data_window.h:56:3: error: 'off64_t' does not name a type; did you mean 'off_t'?)

https://sourceware.org/bugzilla/show_bug.cgi?id=30779 --- Comment #9 from Vladimir Mezentsev --- Has the build problem been fixed in your environment? -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gprofng/31123] improvements to hardware event implementation

https://sourceware.org/bugzilla/show_bug.cgi?id=31123 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving t

[Bug gprofng/31109] gprofng not built and installed in a combined binutils+gcc build

https://sourceware.org/bugzilla/show_bug.cgi?id=31109 --- Comment #11 from Vladimir Mezentsev --- I prepared a patch for the releases/gcc-13 branch. Richard Biener rejected my patch for this branch. Which branch should I use? master, trunk or something else? -- You are receiving this mail bec

[Bug gprofng/30195] [display text] Source code location can not be found

https://sourceware.org/bugzilla/show_bug.cgi?id=30195 Vladimir Mezentsev changed: What|Removed |Added CC||robertjenssen at ozemail dot com

[Bug gprofng/31121] gprofng does not recognise source in a shared object

https://sourceware.org/bugzilla/show_bug.cgi?id=31121 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASS

[Bug gprofng/29593] error: '__u64' undeclared (first use in this function) for aarch64-linux-musl host

https://sourceware.org/bugzilla/show_bug.cgi?id=29593 Vladimir Mezentsev changed: What|Removed |Added See Also||https://sourceware.org/bugz

[Bug gprofng/30779] gprofng: fails to build with musl-1.2.4 (gprofng/src/Data_window.h:56:3: error: 'off64_t' does not name a type; did you mean 'off_t'?)

https://sourceware.org/bugzilla/show_bug.cgi?id=30779 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED See Also|

[Bug gprofng/29477] Build failure on musl: collector_module.h:78:13: error: duplicate member ‘pwrite’

https://sourceware.org/bugzilla/show_bug.cgi?id=29477 Vladimir Mezentsev changed: What|Removed |Added See Also||https://sourceware.org/bugz

[Bug gprofng/31121] gprofng does not recognise source in a shared object

https://sourceware.org/bugzilla/show_bug.cgi?id=31121 --- Comment #17 from Vladimir Mezentsev --- > $ dnf list installed binutils-gprofng > Installed Packages > binutils-gprofng.x86_64 2.40-13.fc39 > @fedora > $ gprofng --version > GNU gprofng binutils versio

[Bug gprofng/31169] [display text] Source code locations can not be found in a C++ application

https://sourceware.org/bugzilla/show_bug.cgi?id=31169 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNE

[Bug gprofng/31121] gprofng does not recognise source in a shared object

https://sourceware.org/bugzilla/show_bug.cgi?id=31121 --- Comment #15 from Vladimir Mezentsev --- If you run: % gp-display-src -dis Fbin2SD test.1.er/archives/bin2SD.oct_IGooCa1n7J2 Annotated disassembly --- Source file: /home/robj/TMP/DesignOfIIRFilters/src/

[Bug gprofng/31169] [display text] Source code locations can not be found in a C++ application

https://sourceware.org/bugzilla/show_bug.cgi?id=31169 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving t

[Bug gprofng/31121] gprofng does not recognise source in a shared object

https://sourceware.org/bugzilla/show_bug.cgi?id=31121 Vladimir Mezentsev changed: What|Removed |Added See Also||https://sourceware.org/bugz

[Bug gprofng/31169] [display text] Source code locations can not be found in a C++ application

https://sourceware.org/bugzilla/show_bug.cgi?id=31169 Vladimir Mezentsev changed: What|Removed |Added See Also||https://sourceware.org/bugz

[Bug gprofng/31109] gprofng not built and installed in a combined binutils+gcc build

https://sourceware.org/bugzilla/show_bug.cgi?id=31109 --- Comment #10 from Vladimir Mezentsev --- I don't have permissions for `git push`. I fixed the problem after: % git branch master * releases/gcc-13 trunk % git cherry-pick 24552056fd5fc677c0d032f54a5cad1c4303d312 Performing inexact re

[Bug gprofng/31121] gprofng does not recognise source in a shared object

https://sourceware.org/bugzilla/show_bug.cgi?id=31121 --- Comment #10 from Vladimir Mezentsev --- Was the problem that parts of bin2SD.oct do not contain debugging information ? Or do you think this is a problem in gprofng? -- You are receiving this mail because: You are on the CC list for the

[Bug gprofng/31116] gprofng test fails with "comparison of results in synprog failed" on x86_64-linux-gnu

https://sourceware.org/bugzilla/show_bug.cgi?id=31116 --- Comment #1 from Vladimir Mezentsev --- What is an output of these commands ? % cat tmpdir/synprog.-g-O0,-pon/display.log % cat tmpdir/synprog.-g-O0,-pon/diff.out % cat tmpdir/synprog.-g-O0,-pon/test.er/warnings.xml I think this is not

[Bug gprofng/31121] gprofng does not recognise source in a shared object

https://sourceware.org/bugzilla/show_bug.cgi?id=31121 --- Comment #9 from Vladimir Mezentsev --- >> Does gprofng assume that shared objects have a .so suffix? No. >> $ gprofng collect app octave -p src --eval "y=bin2SD(48.3,16,3)" >> Creating experiment directory test.2.er (Process ID: 168406

[Bug gprofng/31121] gprofng does not recognise source in a shared object

https://sourceware.org/bugzilla/show_bug.cgi?id=31121 --- Comment #7 from Vladimir Mezentsev --- OK. The code looks similar. I cannot see source because /home/robj/CHANGES/DesignOfIIRFilters.C1406/src/bin2SD.cc is not available. When you use gprofng, do you see sources for Gbin2SD. -- You are

[Bug gprofng/31121] gprofng does not recognise source in a shared object

https://sourceware.org/bugzilla/show_bug.cgi?id=31121 --- Comment #5 from Vladimir Mezentsev --- What function would you like to see ? As I can see a part of bin2SD.oct was built with -g. For example: % gp-display-src -dis Gbin2SD bin2SD.oct Annotated disassembly --

[Bug gprofng/31121] gprofng does not recognise source in a shared object

https://sourceware.org/bugzilla/show_bug.cgi?id=31121 Vladimir Mezentsev changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug gprofng/31121] gprofng does not recognise source in a shared object

https://sourceware.org/bugzilla/show_bug.cgi?id=31121 --- Comment #1 from Vladimir Mezentsev --- Typically gprofng cannot recognize the source if a shared object was built without -g or stripped. Can you see DWARF: dwarfdump YOUR_SHARED_OBJECT or objdump -W YOUR_SHARED_OBJECT -- You are rec

[Bug gprofng/31109] gprofng not built and installed in a combined binutils+gcc build

https://sourceware.org/bugzilla/show_bug.cgi?id=31109 --- Comment #8 from Vladimir Mezentsev --- Oops. I forgot to create links to binutils-2_41-branch. Now I can build, install and run gprofng without warnings/errors. I use gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-16.0.2) I built on an x86_64/OL

[Bug gprofng/31116] gprofng test fails with "comparison of results in synprog failed" on x86_64-linux-gnu

https://sourceware.org/bugzilla/show_bug.cgi?id=31116 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving t

[Bug gprofng/31109] gprofng not built and installed in a combined binutils+gcc build

https://sourceware.org/bugzilla/show_bug.cgi?id=31109 --- Comment #7 from Vladimir Mezentsev --- I configured my gcc trank build: /configure --prefix=`pwd`/INSTALL --enable-gprofng I see the binutils-gdb targets in Makefile. For example: % grep gprof Makefile maybe-configure-gprof \

[Bug gprofng/31109] gprofng not built and installed in a combined binutils+gcc build

https://sourceware.org/bugzilla/show_bug.cgi?id=31109 --- Comment #6 from Vladimir Mezentsev --- I removed only compiler errors to continue my build. Like this: % diff $old_binutils/libctf/ctf-hash.c libctf/ctf-hash.c 168,169c168,169 < else < dynhash = malloc (offsetof (ctf_dynhash_t, key_

[Bug gprofng/31109] gprofng not built and installed in a combined binutils+gcc build

https://sourceware.org/bugzilla/show_bug.cgi?id=31109 --- Comment #4 from Vladimir Mezentsev --- I cannot reproduce the problem. I cloned http://gcc.gnu.org/git/gcc.git and copied all directories from binutils-gdb. I see an error in the libctf build: ../../libctf/ctf-hash.c: In function ‘ctf

[Bug gprofng/30895] gprofng is not relocatable

https://sourceware.org/bugzilla/show_bug.cgi?id=30895 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNE

[Bug gprofng/30894] bison should be no hard dependency

https://sourceware.org/bugzilla/show_bug.cgi?id=30894 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNE

[Bug gprofng/30910] gprofng cross test fail: can't read "CHECK_TARGET": no such variable

https://sourceware.org/bugzilla/show_bug.cgi?id=30910 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Vla

[Bug gprofng/30894] bison should be no hard dependency

https://sourceware.org/bugzilla/show_bug.cgi?id=30894 Vladimir Mezentsev changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0

[Bug gprofng/30895] gprofng is not relocatable

https://sourceware.org/bugzilla/show_bug.cgi?id=30895 Vladimir Mezentsev changed: What|Removed |Added Ever confirmed|0 |1 Assignee|vladimir.me

[Bug gprofng/30896] gprofng display text: please provide a way (or document how) to include the object name next to the called functions

https://sourceware.org/bugzilla/show_bug.cgi?id=30896 Vladimir Mezentsev changed: What|Removed |Added Last reconfirmed||2023-09-27 Ever confirmed|0

[Bug gprofng/30898] consider multi-threading for gprofng display text

https://sourceware.org/bugzilla/show_bug.cgi?id=30898 --- Comment #3 from Vladimir Mezentsev --- Hi Ruud, See the end of emil. He suggests to remove the disassembly by default in gp-display-html On 9/26/23 11:09, bugmenot at mailinator dot com wrote: > https://sourceware.org/bugzilla/show_bug.

[Bug gprofng/30898] consider multi-threading for gprofng display text

https://sourceware.org/bugzilla/show_bug.cgi?id=30898 Vladimir Mezentsev changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug gprofng/30897] Support source view for "referenced" source (e.g. bison)

https://sourceware.org/bugzilla/show_bug.cgi?id=30897 Vladimir Mezentsev changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug gprofng/30896] gprofng display text: please provide a way (or document how) to include the object name next to the called functions

https://sourceware.org/bugzilla/show_bug.cgi?id=30896 --- Comment #1 from Vladimir Mezentsev --- % gprofng display text -name short:soname -func test.1.er/ Functions sorted by metric: Exclusive Total CPU Time Excl. Total Incl. TotalName CPU CPU sec. % sec. % 0.060 1

[Bug gprofng/30834] improve disassembly output for call and branch instructions

https://sourceware.org/bugzilla/show_bug.cgi?id=30834 Vladimir Mezentsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug gprofng/30834] improve disassembly output for call and branch instructions

https://sourceware.org/bugzilla/show_bug.cgi?id=30834 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving t

[Bug gprofng/30834] New: improve disassembly output for call and branch instructions

Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: vladimir.mezentsev at oracle dot com Target Milestone: --- gprofng only displays the hexadecimal address in call and jump instructions: % gprofng display src -dis main

[Bug gprofng/30808] gprofng tests failed

https://sourceware.org/bugzilla/show_bug.cgi?id=30808 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNE

[Bug gprofng/30808] gprofng tests failed

https://sourceware.org/bugzilla/show_bug.cgi?id=30808 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving t

[Bug gprofng/30808] New: gprofng tests failed

Assignee: vladimir.mezentsev at oracle dot com Reporter: vladimir.mezentsev at oracle dot com Target Milestone: --- 1. 3 tests failed without --enable-shared: % mkdir x86_64-linux-gnu % cd x86_64-linux-gnu % ../configure --target=x86_64-linux-gnu --disable-gdb --disable-sim % make -j 20

[Bug gprofng/30779] gprofng: fails to build with musl-1.2.4 (gprofng/src/Data_window.h:56:3: error: 'off64_t' does not name a type; did you mean 'off_t'?)

https://sourceware.org/bugzilla/show_bug.cgi?id=30779 --- Comment #2 from Vladimir Mezentsev --- I don't use musl. But I fixed couple bugs in gprofng to build on x86_64-pc-linux-musl. I did on my machine: % wget https://distfiles.adelielinux.org/adelie/1.0/iso/rc2/adelie-rootfs-mini-x86_64-1.0-r

[Bug gprofng/30700] tmpdir/gp-collect-app_F test fails

https://sourceware.org/bugzilla/show_bug.cgi?id=30700 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNE

[Bug gprofng/30700] tmpdir/gp-collect-app_F test fails

https://sourceware.org/bugzilla/show_bug.cgi?id=30700 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #10 from Vl

[Bug gprofng/30700] tmpdir/gp-collect-app_F test fails

https://sourceware.org/bugzilla/show_bug.cgi?id=30700 --- Comment #7 from Vladimir Mezentsev --- We should OK with this libc. What version of Linux are you using? I will try to reproduce the problem tomorrow. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gprofng/30700] tmpdir/gp-collect-app_F test fails

https://sourceware.org/bugzilla/show_bug.cgi?id=30700 --- Comment #4 from Vladimir Mezentsev --- Use the -D flag: % nm -D /usr/lib/x86_64-linux-gnu/libpthread.so.0 | grep pthread_create -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gprofng/30700] tmpdir/gp-collect-app_F test fails

https://sourceware.org/bugzilla/show_bug.cgi?id=30700 --- Comment #2 from Vladimir Mezentsev --- It looks like libpthread has a new version number for pthread_create. What is an output of `nm /usr/lib/libpthread.so | grep pthread_create` on your machine. -- You are receiving this mail because

[Bug gprofng/30679] gprofng man pages improvements

https://sourceware.org/bugzilla/show_bug.cgi?id=30679 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|vlad

  1   2   3   >