[valgrind] [Bug 415293] Incorrect call-graph tracking due to new _dl_runtime_resolve_xsave* functions
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
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:
...
if (HAS_ARCH_FEATURE (AVX512F_Usable))
*(ElfW(Addr) *) (got + 2) = (ElfW(Addr))
&_dl_runtime_profile_avx512;
else if (HAS_ARCH_FEATURE (AVX_Usable))
*(ElfW(Addr) *) (got + 2) = (ElfW(Addr)) &_dl_runtime_profile_avx;
else
*(ElfW(Addr) *) (got + 2) = (ElfW(Addr)) &_dl_runtime_profile_sse;
...
because of check for cpu features, a reproducer environment to validate all
entries, or experiment with automatic detection might need custom VMs.
--
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
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 example run: $ ls *_out.out callgrind_cacheprofiling_7020_out.out callgrind_cacheprofiling_7021_out.out $ grep dl_runtime_resolve *.out callgrind_cacheprofiling_7020_out.out:cfn=(422) _dl_runtime_resolve_xsave callgrind_cacheprofiling_7020_out.out:fn=(423) _dl_runtime_resolve_xsave'2 only the sample output without LD_BIND_NOW set shows _dl_runtime_resolve*. -- 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
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 has it working on rhel7 using the attached patch and the command line option --dl-runtime-resolve-pattern=PATTERN where PATTERN is either: amd64-def amd64-xsavec amd64-xsave amd64-fxsave and the most common should be amd64-xsave, so, testing it before amd64-xsavec would make it work most times without the option. This is specific to rhel7 or centos7 and x86_64. The patch checks for /usr/lib/ld and /usr/lib64/ld patterns, otherwise it would not even check the patterns, then, checks patterns in the order above, but because it needs to use only one, the option was required. -- 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
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 a
function matching the initial _dl_runtime_resolve is called, use the
existing code.
A quick grep shows "EXT" as _xsave, _xsavec, _fxsave, _old, _new,
_0, _1, _avx, _avx512, _sse, _sse_vex, _opt... On different versions
of recent (2 or less years) glibc trees.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 415293] New: Incorrect call-graph tracking due to new _dl_runtime_resolve_xsave* functions
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 OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: callgrind Assignee: josef.weidendor...@gmx.de Reporter: paulo.cesar.pereira.de.andr...@gmail.com Target Milestone: --- Newer glibc have alternate ld.so _ld_runtime_resolve functions. Namely _dl_runtime_resolve_xsave and _dl_runtime_resolve_xsave'2 Those exist to save the full AVX registers, for applications that somewhat use an 'extended' x86_64 ABI. The problem is that applications need to run with LD_BIND_NOW set for kcachegrind to have some more meaningful usage. I believe callgrind/fn.c should be extended to handle these new ld.so symbols. (BTW, it appears there is a minor typo in the comments of callgrind/fn.c, that tell about _ld_runtime_resolve, but check for _dl_runtime_resolve). -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 411645] Make sagemath backend compatible with sagemath built with python3
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 currently only the latest Fedora sagemath packages are built with python3. -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 411645] Make sagemath backend compatible with sagemath built with python3
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 Cantor sage backend, and on my machine (SageMath
> 8.7 based on python2) one of them is failed (TestSage::testPlot(),
> testsage.cpp::92).
>
> So, on this moment, I can't accept the patch, because it breaks appearing of
> plots appearing for SageMath, based on python2.
>
> But, anyway, this problem is important, so, if this patch won't be improved
> for working with Python2, I think, I just will add a option "SageMath python
> 3 compatibility".
Many thanks for checking it. I am not much familiar with phabricator.kde.org
For some reason, while working on parallel with several issues related
to the sagemath rpm package, when submitting the report I though the patch
could be simplified, but it cannot.
The proper line for two arguments would be:
print("%s %s" % ('TMP_DIR', sage.misc.misc.SAGE_TMP))
python2 would generate different output. For example:
$ python2 -c 'print("foo", "bar")'
('foo', 'bar')
$ python3 -c 'print("foo", "bar")'
foo bar
$ python2 -c 'print("%s %s" % ("foo", "bar"))'
foo bar
I was actually testing a patch with the later version, but got confused and
for some reason thought it could be simplified.
--
You are receiving this mail because:
You are watching all bug changes.
[cantor] [Bug 411646] New: Please consider adding a configuration to use local sagemath documentation
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 Status: REPORTED Severity: normal Priority: NOR Component: sage-backend Assignee: cantor-b...@kde.org Reporter: paulo.cesar.pereira.de.andr...@gmail.com Target Milestone: --- In newer cantor 19.08 several backends have an option to set a path to local documentation. Please consider adding it also for the sagemath backend. Both, the upstream sagemath tarball and at least Fedora sagemath provide local documentation. Upstream tarball is $SAGE_ROOT/local/share/doc/sage/html/$LANG/index.html and the Fedora package has it at $SAGE_ROOT/doc/html/$LANG/index.html -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 411645] New: Make sagemath backend compatible with sagemath built with python3
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 Status: REPORTED Severity: normal Priority: NOR Component: sage-backend Assignee: cantor-b...@kde.org Reporter: paulo.cesar.pereira.de.andr...@gmail.com Target Milestone: --- Created attachment 122512 --> https://bugs.kde.org/attachment.cgi?id=122512=edit cantor-sagemath-python3.patch I am working on some updates to the Fedora sagemath package. This attached patch works with both, python2 and python3. The reason of the patch is self described below: $ python3 -c 'print 1, 2' File "", line 1 print 1, 2 ^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1, 2)? $ python3 -c 'print(1, 2)' 1 2 -- You are receiving this mail because: You are watching all bug changes.
