Bug 32611 - readelf: error: unknown argument '-w'
Summary: readelf: error: unknown argument '-w'
Status: UNCONFIRMED
Alias: None
Product: dwz
Classification: Unclassified
Component: default (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-01-29 01:59 UTC by Zhixu Liu
Modified: 2025-03-28 09:00 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
patch to fix issue if using llvm-readelf (774 bytes, text/plain)
2025-01-29 01:59 UTC, Zhixu Liu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zhixu Liu 2025-01-29 01:59:10 UTC
Created attachment 15904 [details]
patch to fix issue if using llvm-readelf

Gentoo have theses two patches applied (for musl) which seems haven't be applied?

see https://sourceware.org/pipermail/dwz/2024q4/001434.html and https://sourceware.org/pipermail/dwz/2024q4/001435.html

if using llvm profile and using llvm-readelf, build will failed:

> readelf: error: unknown argument '-w'

the reason is NATIVE_POINTER_SIZE is determined by readelf, but lvm-readelf has different arguments w/ gnu readelf, it doesn't accept "-wi".

llvm-dwarfdump can be used to get addr_size,

> # llvm-dwarfdump --debug-line
var/tmp/portage/sys-devel/dwz-0.15-r4/work/dwz/native.o
> ...
>    address_size: 8
> ...

can be replaced if know how llvm-readelf get pointer size
Comment 1 Mark Wielaard 2025-03-25 16:57:05 UTC
Can you make sure to have binutils readelf installed?
I rather not try supporting both binutils readelf and llvm dwarfdump in the testsuite. Matching output of one is tricky enough.
Comment 2 Zhixu Liu 2025-03-26 02:39:19 UTC
(In reply to Mark Wielaard from comment #1)
> Can you make sure to have binutils readelf installed?
> I rather not try supporting both binutils readelf and llvm dwarfdump in the
> testsuite. Matching output of one is tricky enough.

In Gentoo, when using llvm profile, readelf is:

# which readelf
/usr/lib/llvm/19/bin/readelf
 # ls -l /usr/lib/llvm/19/bin/readelf
lrwxrwxrwx 1 root root 12 12月23日 15:58 /usr/lib/llvm/19/bin/readelf -> llvm-readelf

and binutils is nstalled, but executables are not installed in search path:

/usr/x86_64-pc-linux-gnu/binutils-bin/2.44/readelf

proposed Gentoo PR is at
https://github.com/gentoo/gentoo/pull/40327
Comment 3 Mark Wielaard 2025-03-26 12:23:25 UTC
Sounds like a bad idea for gentoo to name something readelf if it isn't command line compatible with (binutils) readelf, especially if the output also doesn't match.
Comment 4 Sam James 2025-03-26 12:25:29 UTC
It's not quite what we're doing. It exists as a fallback on PATH if nothing else exists (/usr/lib/llvm/*/bin is way after /usr/bin and so on).

I would expect GNU Binutils readelf to be earlier on PATH if it's available at all...
Comment 5 Mark Wielaard 2025-03-26 12:29:38 UTC
Aha, ok, then we can just close this bug with as note that to make/check dwz you have to make sure binutils readelf is on the PATH?

A patch to detect that readelf isn't usable would be appreciated though.
Comment 6 Jakub Jelinek 2025-03-26 12:35:19 UTC
(In reply to Sam James from comment #4)
> It's not quite what we're doing. It exists as a fallback on PATH if nothing
> else exists (/usr/lib/llvm/*/bin is way after /usr/bin and so on).
> 
> I would expect GNU Binutils readelf to be earlier on PATH if it's available
> at all...

Even then it looks like a bad idea.  Argument and output incompatible program shouldn't be called the same, if users want the llvm version, they should use the llvm- prefixed one, or readelf should be a script that transforms readelf arguments to llvm-readelf arguments and changes output to match the expectations.
Guess same mistake is to call clang gcc or vice versa, while they have some options in common, there are many incompatible options and the compilers behave quite differently in many ways.
Comment 7 Zhixu Liu 2025-03-28 08:43:42 UTC
https://sourceware.org/pipermail/dwz/2024q4/001435.html

is it possible to merge this patch?
Comment 8 Mark Wielaard 2025-03-28 09:00:31 UTC
(In reply to Zhixu Liu from comment #7)
> https://sourceware.org/pipermail/dwz/2024q4/001435.html
> 
> is it possible to merge this patch?

Note that it was discussed on list and there were some (unanswered) questions about it:
https://inbox.sourceware.org/dwz/892b7edc860b8d1530560bc4f796c93f26098715.camel@klomp.org/T/#u