[valgrind] [Bug 415293] Incorrect call-graph tracking due to new _dl_runtime_resolve_xsave* functions

2020-07-29 Thread pcpa
https://bugs.kde.org/show_bug.cgi?id=415293 --- Comment #7 from pcpa --- Appears to work for me. I will confirm with the person that pointed out the problem if it works on their environment, but unlikely to not work. -- You are receiving this mail because: You are watching all bug changes.

[valgrind] [Bug 415293] Incorrect call-graph tracking due to new _dl_runtime_resolve_xsave* functions

2020-05-25 Thread pcpa
https://bugs.kde.org/show_bug.cgi?id=415293 --- Comment #5 from pcpa --- It should be tricky to figure what version is being used. Could look into the 'the elf_machine_runtime_setup' function in sysdeps/${ARCH}/dl-machine.h glibc source. Sample chunk from rhel7 x86_64 source

[valgrind] [Bug 415293] Incorrect call-graph tracking due to new _dl_runtime_resolve_xsave* functions

2020-05-25 Thread pcpa
https://bugs.kde.org/show_bug.cgi?id=415293 --- Comment #4 from pcpa --- Created attachment 128770 --> https://bugs.kde.org/attachment.cgi?id=128770=edit sample_callgrind.tgz This a reproducer from a Red Hat user. The repro.sh script works with or without devtoolset installed. On a exam

[valgrind] [Bug 415293] Incorrect call-graph tracking due to new _dl_runtime_resolve_xsave* functions

2020-03-04 Thread pcpa
https://bugs.kde.org/show_bug.cgi?id=415293 --- Comment #2 from pcpa --- Created attachment 126591 --> https://bugs.kde.org/attachment.cgi?id=126591=edit valgrind-3.14.0-rhbz1784541.patch This is a suggested patch or possible way to handle the issue. The user that had the issue now

[valgrind] [Bug 415293] Incorrect call-graph tracking due to new _dl_runtime_resolve_xsave* functions

2019-12-18 Thread pcpa
https://bugs.kde.org/show_bug.cgi?id=415293 --- Comment #1 from pcpa --- As an extra note, there are several different _dl_runtime_resolve{EXT} variants. I believe only one is used in an application, but there are multiple names. A possible fix is to use the logic in callgrind/fn.c so that when

[valgrind] [Bug 415293] New: Incorrect call-graph tracking due to new _dl_runtime_resolve_xsave* functions

2019-12-17 Thread pcpa
https://bugs.kde.org/show_bug.cgi?id=415293 Bug ID: 415293 Summary: Incorrect call-graph tracking due to new _dl_runtime_resolve_xsave* functions Product: valgrind Version: 3.15 SVN Platform: RedHat RPMs

[cantor] [Bug 411645] Make sagemath backend compatible with sagemath built with python3

2019-12-05 Thread pcpa
https://bugs.kde.org/show_bug.cgi?id=411645 --- Comment #4 from pcpa --- Hi, Yes, it would be a good change to cantor. This change will make cantor work if sagemath is built with python3 or python2. Currently upstream is building with python2, but is finishing porting to python3. I believe

[cantor] [Bug 411645] Make sagemath backend compatible with sagemath built with python3

2019-09-09 Thread pcpa
https://bugs.kde.org/show_bug.cgi?id=411645 --- Comment #2 from pcpa --- (In reply to Nikita Sirgienko from comment #1) > Hi > > First, if you are familiar with development, then there is > phabricator.kde.org for suggestions like this. > Second, there is tests for Cant

[cantor] [Bug 411646] New: Please consider adding a configuration to use local sagemath documentation

2019-09-06 Thread pcpa
https://bugs.kde.org/show_bug.cgi?id=411646 Bug ID: 411646 Summary: Please consider adding a configuration to use local sagemath documentation Product: cantor Version: 19.08 Platform: Other OS: Linux

[cantor] [Bug 411645] New: Make sagemath backend compatible with sagemath built with python3

2019-09-06 Thread pcpa
https://bugs.kde.org/show_bug.cgi?id=411645 Bug ID: 411645 Summary: Make sagemath backend compatible with sagemath built with python3 Product: cantor Version: unspecified Platform: Other OS: Linux