https://bugzilla.redhat.com/show_bug.cgi?id=2180989
--- Comment #21 from Bernhard Kaindl <bernhard(a)mailo.com> ---
Thanks for the review. About the output from fedora-review:
uftrace.x86_64: E: shared-library-without-dependency-information
/usr/lib64/uftrace/libmcount-nop.so
$ rpmlint -e shared-library-without-dependency-information
shared-library-without-dependency-information:
The listed shared library doesn't include information about which other
libraries the library was linked against.
Not sure why getting this.
rpmlint issues this error because this isn't regular library:
It is shared object is preloaded using LD_PRELOAD as one of the data points for
benchmarching the individual tracing mechanism.
This specific shared object only contains dummy functions to for benchmarking
the nearly perfect case, which is that functions are instrumented for tracing,
but the tracing itself has zero impact. This is why this shared has only dumy
functions which don't call into other code has no other depencies which could
affect the performance of the benchmark.
While it would usually be a strange sign when a *.so file has no dependencies,
this this case, this check is expected to be raised.
You can roughly compare files like these with the *.so files of the valgrind
package:
It is a tracing tool as well and also in valgrind, these files are special.
Other example *.so files which are preloaded and do not fall into the category
of regular libaries are for example:
- libfakeroot.so from the fakeroot package:
https://src.fedoraproject.org/rpms/fakeroot
- libpseudo.so from the pseudo package:
https://packages.fedoraproject.org/pkgs/pseudo/pseudo/
- libmtrace.so for memory allocation tracing
https://github.com/sergey-senozhatsky/libmtrace
- gprofng:
https://blogs.oracle.com/linux/post/gprofng-the-next-generation-gnu-profi...
In test suites, this situation is usually be summarized as an XFAIL: As fail
which is expected and correct in such cases.
---
uftrace.x86_64: W: position-independent-executable-suggested
/usr/bin/uftrace
$ rpmlint -e position-independent-executable-suggested
position-independent-executable-suggested:
This executable should be position independent (all binaries should). Check
that it is built with -fPIE/-fpie in compiler flags and -pie in linker flags.
-fPIE should be in compiler flags, but consider adding
LDFLAGS=$(LDFLAGS) -pie
to the spec file
Here is the part of the FPG about PIE:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_pie, it says:
In Fedora, PIE is enabled by default. To disable it in your spec,
add:
%undefine _hardened_build
If your package meets any of the following criteria you MUST NOT disable the PIE compiler
flags:
- Your package is long running. This means it’s likely to be started and keep running
until the machine is rebooted, not start on demand and quit on idle.
- Your package has suid binaries, or binaries with capabilities.
- Your package runs as root.
Because I've seend and verified that using -fPIE causes regressions in the test
suite, I am invoking this exception as described above.
- Using it leads to regressions because of the low-level nature of tracing on
the assembly and register level:
(even patching instructions at dynamically at runtime)
- It is not long-running (as defined in the FPG), does not run as root and has
no suid binaries or binaries with capabilities.
Thus, like gcc, which also disables _hardened_build, the FPC allowes them be
built without PIE in order to have no regressions:
https://src.fedoraproject.org/rpms/gcc/blob/rawhide/f/gcc.spec
uftrace.x86_64: W: binary-or-shlib-calls-gethostbyname
/usr/bin/uftrace
$ rpmlint -e binary-or-shlib-calls-gethostbyname
binary-or-shlib-calls-gethostbyname:
The binary calls gethostbyname. Please port the code to use getaddrinfo.
Maybe upstream will update or accept a patch?
Patch submitted upstream, will likely be merged, I hope:
https://github.com/namhyung/uftrace/pull/1661
Thanks for your review.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
https://bugzilla.redhat.com/show_bug.cgi?id=2180989