Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#42700 - [namcap] use readelf instead of eu-findtextrel to check text relocation

Attached to Project: Arch Linux
Opened by Jiachen Yang (farseerfc) - Thursday, 06 November 2014, 18:28 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 19 December 2016, 05:45 GMT
Task Type Feature Request
Category Arch Projects
Status Closed
Assigned To Rémy Oudompheng (remyoudompheng)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
Since  FS#26434 , namcap start to warn on TEXTREL in shared object, which itself is good.
But we encountered a long running time of namcap executing eu-findtextrel on our recent build of pypy-hg.
The process of eu-findtextrel checking opt/pypy/bin/libpypy-c.so keeps running for more than 20 minutes.

I looked into the source code of eu-findtextrel, and I read this page: http://www.akkadia.org/drepper/textrelocs.html .
I found that finding whether a elf has text relocation is quite simple, we can just do:
$ readelf -d path/to/elf.so | grep "\\(TEXTREL\\)"
to see whether it got result.
Running eu-findtextrel on the elf is actually trying to resolve all the function symbols that got compiled without -fPIC, which involves much more calculations.

The namcap don't need these outputs of eu-findtextrel because the stdout and stderr are redirected to /dev/null.
It only depends on the return value of eu-findtextrel, which indicates whether the elf file has text relocation sections.
Therefore I would like to recommend the namcap to use readelf rather than eu-findtextrel to check text relocations on elf files.

Additional info:
* package version(s)
namcap 3.2.5-2
* config and/or log files etc.


Steps to reproduce:
I uploaded the problematic libpypy-c.so here (larger than 2MiB after being compressed):
https://www.dropbox.com/s/4q9epvbbd2qtyy3/libpypy-c.so.xz?dl=0
This so file is made by devtools and extracted from pypy-hg-74351.34433ac979df-1-i686.pkg.tar.xz
You can download the libpypy-c.so.xz file, decompress it, and test:
$ eu-findtextrel libpypy-c.so
(very long output and more than 20 minutes)

And as contrast, test with readelf:
$ time readelf -d libpypy-c.so | grep "\\(TEXTREL\\)"
0x00000016 (TEXTREL) 0x0
0x0000001e (FLAGS) TEXTREL STATIC_TLS
readelf -d opt/pypy/bin/libpypy-c.so 0.01s user 0.01s system 91% cpu 0.022 total
grep --color "\\(TEXTREL\\)" 0.00s user 0.00s system 15% cpu 0.021 total
This task depends upon

Closed by  Doug Newgard (Scimmia)
Monday, 19 December 2016, 05:45 GMT
Reason for closing:  Fixed
Comment by Jiachen Yang (farseerfc) - Friday, 07 November 2014, 05:22 GMT
I would like to propose the following quick fix to Namcap/rules/elffiles.py .


--- elffiles.py 2014-11-07 15:23:34.120406707 +0900
+++ /home/farseerfc/elffiles.py 2014-11-07 15:21:47.014097022 +0900
@@ -93,10 +93,9 @@
continue

try:
- ret = subprocess.call(["eu-findtextrel", tmpname],
- stdout=open(os.devnull, 'w'),
- stderr=open(os.devnull, 'w'))
- if ret == 0:
+ output = subprocess.check_output(["readelf", "-d", tmpname],
+ stderr=subprocess.DEVNULL)
+ if b"(TEXTREL)" in output:
files_with_textrel.append(entry.name)
finally:
os.unlink(tmpname)
Comment by Kyle Keen (keenerd) - Saturday, 10 December 2016, 18:09 GMT
Should be fixed in commit 11ace73 but I can't easily test it since I can't find any packages with a TEXTREL.

(The fix also removes subprocess and tempfile entirely. Should be a bit faster.)

Loading...