Hi,
This small patch to readelf.c displays the library name from which a dynamic symbol of specific version should be resolved.
===== diff --git a/src/readelf.c b/src/readelf.c index 5255860..c8c37f0 100644 --- a/src/readelf.c +++ b/src/readelf.c @@ -2068,9 +2068,11 @@ handle_symtab (Ebl *ebl, Elf_Scn *scn, GElf_Shdr *shdr)
if (vernaux != NULL && vernaux->vna_other == *versym) { - printf ("@%s (%u)", + printf ("@%s %s (%u)", elf_strptr (ebl->elf, verneed_stridx, vernaux->vna_name), + elf_strptr (ebl->elf, verneed_stridx, + verneed->vn_file), (unsigned int) vernaux->vna_other); check_def = 0; } =====
Sample output: (edited to fit in space) looks like
===== $ ./readelf -s ar
0: ... DEFAULT UNDEF 1: ... DEFAULT UNDEF __errno_location@GLIBC_2.0 libc.so.6 (2) 2: ... DEFAULT UNDEF gelf_getsym@ELFUTILS_1.0 libelf.so.1 (3) 3: ... DEFAULT UNDEF basename@GLIBC_2.0 libc.so.6 (2) 4: ... DEFAULT UNDEF elf_strptr@ELFUTILS_1.0 libelf.so.1 (3) 5: ... DEFAULT UNDEF sysconf@GLIBC_2.0 libc.so.6 (2) 6: ... DEFAULT UNDEF memcmp@GLIBC_2.0 libc.so.6 (2) 7: ... DEFAULT UNDEF open64@GLIBC_2.1 libc.so.6 (4) 8: ... DEFAULT UNDEF elf_getdata@ELFUTILS_1.0 libelf.so.1 (3) 9: ... DEFAULT UNDEF __fsetlocking@GLIBC_2.2 libc.so.6 (5)
...
=====
I would really appreciate it if it gets accepted for the main branch, as that'll be a lot of help to me.
Thank you. -- Regards - Prasad
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/27/2010 01:08 AM, P J P wrote:
I would really appreciate it if it gets accepted for the main branch, as that'll be a lot of help to me.
This information is already available in the output and adding yet more test to already long lines doesn't help readability. I don't like this change one bit.
- -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/27/2010 02:13 AM, P J P wrote:
No, library name is not displayed with the dynamic symbols.
The .gnu.version section does.
and adding yet more test to already long lines doesn't help readability.
yet more test?
text
- -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
On Tue, 27 Apr 2010, Ulrich Drepper wrote:
The .gnu.version section does.
Yes; But having library name right next to the symbol name, like symbol version, is way more convenient than searching version index in the .gnu.version to get the library name. It helps a lot when a file has hundreds of symbols. Besides .gnu.version is not displayed with the `-s' option.
-- Regards - Prasad
On Tue, 27 Apr 2010, P J P wrote:
Yes; But having library name right next to the symbol name, like symbol version, is way more convenient than searching version index in the .gnu.version to get the library name. It helps a lot when a file has hundreds of symbols. Besides .gnu.version is not displayed with the `-s' option.
doesn't it make sense?
-- Regards - Prasad
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/27/2010 02:46 AM, P J P wrote:
Yes; But having library name right next to the symbol name, like symbol version, is way more convenient than searching version index in the .gnu.version to get the library name.
It's not more convenient if you cannot recognize anything because the line is too long. There is a reason why the information is split. And nobody is forcing you to use -s only.
- -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
On Tue, 27 Apr 2010, Ulrich Drepper wrote:
-----BEGIN PGP SIGNED MESSAGE----- It's not more convenient if you cannot recognize anything because the line is too long.
Well, the fields are separated by space and recognizing them is not as difficult as you think it is. Besides I'm sure you do realise that one has no control over the line length, for it's a pure function of symbol name, which could be of *any* length. Adding 10-15 character library name to an already *long* line is not going to hamper it's readability as much as you think. And even if, let's say, it does to some extent, the cost of that long length and readability seems affordable when compared to the utility of the information and convenience it offers to the user, don't you think so?
There is a reason why the information is split.
I'm sure there is reason why information is split. But please don't overlook the fact that all the reasons and information split is not helping the user as much as it could.
Let's take a look at the information split, the .gnu_version section displayed by option -V shows
Even symbol index: version index version name(library name)
Of which -s already gives us the version index and version name along with the symbol name, right? Then why leave library name in .gnu_version, when it could be of much more help seen next to a symbol name, just for the line length, seriously? No offence but that sounds like my friend's father-in-law who said he won't let his daughter marry my friend because he(my friend) is bald.
And nobody is forcing you to use -s only.
I know nobody is forcing me to use -s only. But as I said, using -sV together is not as convenient/easy option as you make it sound.
-- Regards - Prasad
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/27/2010 11:17 PM, P J P wrote:
And even if, let's say, it does to some extent, the cost of that long length and readability seems affordable when compared to the utility of the information and convenience it offers to the user, don't you think so?
No. The current information is perfectly usable. If you look for other information you use the -V option.
If you need help decoding the readelf output use one of the (graphical) frontends to readelf.
- -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
On Tue, 27 Apr 2010, Ulrich Drepper wrote:
No. The current information is perfectly usable. If you look for other information you use the -V option.
Huh...at least don't say it's *perfect*. :(
If you need help decoding the readelf output use one of the (graphical) frontends to readelf.
I don't want to decode anything. I'm just interested in dynamic symbols, their version if any, and the library they come from.
-- Regards - Prasad
eu-readelf -V is already easier than binutils readelf -V, which doesn't look up the SONAMEs for you in the '.gnu.version' dump either. (You have to go find the magic number at the end of a line in the '.gnu.version_r' dump and look back for the File: bit.)
Perhaps we could add a --verbose that makes readelf give more detailed and/or redundant data in various ways such as this. Or perhaps you would like to hack on the "greadelf" program (in Fedora), or something like it. That is a GUI front-end for eu-readelf output. (It looks nutty to me, but I haven't really tried it.) A snazzy one could have enableable columns or tooltips or whatnot for version/soname/etc on symbol table entries.
Thanks, Roland
On Tue, 27 Apr 2010, Roland McGrath wrote:
eu-readelf -V is already easier than binutils readelf -V, which doesn't look up the SONAMEs for you in the '.gnu.version' dump either. (You have to go find the magic number at the end of a line in the '.gnu.version_r' dump and look back for the File: bit.)
I know that; eu-readelf or readelf, in any case I'll have to do the same juggling to find the library name.
Perhaps we could add a --verbose that makes readelf give more detailed and/or redundant data in various ways such as this.
It seriously beats me! You are ready to add a completely new option(ie. more code, more complexities, will take more time and more of everything else), but can not accept a patch, that is insanely small and neat and serves the purpose.
Or perhaps you would like to hack on the "greadelf" program (in Fedora), or something like it. That is a GUI front-end for eu-readelf output. (It looks nutty to me, but I haven't really tried it.) A snazzy one could have enableable columns or tooltips or whatnot for version/soname/etc on symbol table entries.
GUI doesn't help. I just want three columns of text output symbol name, their version and library name.
-- Regards - Prasad
On 04/28/2010 09:49 AM, P J P wrote:
It seriously beats me! You are ready to add a completely new option(ie.
more code, more complexities, will take more time and more of everything else), but can not accept a patch, that is insanely small and neat and serves the purpose.
[...]
GUI doesn't help. I just want three columns of text output symbol name,
their version and library name.
As a user of these tools, not a feudal owner of its development, I think your patch is useful and convenient, and I would be very happy to see it included in the main tree, personally. Thats my personal opinion - non of the contra-arguments given by Ulrich are really productive, imho. From the perspective of a user, its far more useful to have libnames alongside the symbols and not have to go digging around when you're just trying to get work done .. but thats just me.
On Wed, 28 Apr 2010, Jay Vaughan wrote:
As a user of these tools, not a feudal owner of its development, I think your patch is useful and convenient, and I would be very happy to see it included in the main tree, personally. Thats my personal opinion - non of the contra-arguments given by Ulrich are really productive, imho. From the perspective of a user, its far more useful to have libnames alongside the symbols and not have to go digging around when you're just trying to get work done .. but thats just me.
Thanks Jay, I really appreciate it.
Thank you. -- Regards - Prasad
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/28/2010 12:49 AM, P J P wrote:
GUI doesn't help. I just want three columns of text output symbol name, their version and library name.
Then adjust the GUI.
Anyway, programs like that show why the output cannot be changed willy-nilly. There are programs and scripts that parse the output of readelf. Your convenience is absolutely not reason enough to break those.
- -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Anyway, programs like that show why the output cannot be changed willy-nilly. There are programs and scripts that parse the output of readelf. Your convenience is absolutely not reason enough to break those.
Just let him put an arg switch on the output and leave it at that - it won't break anything and it makes the tool more useful to newcomers that are using it to gain an understanding of the subject ..
On Wed, 28 Apr 2010, Ulrich Drepper wrote:
Then adjust the GUI.
didn't I say GUI doesn't help?
Anyway, programs like that show why the output cannot be changed willy-nilly.
programs like what?
There are programs and scripts that parse the output of readelf.
Well, I understand that, and is quite better reason than line length.
As for the scripts/programs that use the readelf output, since the fields in the output are separated by space, and the library name comes in the end, it should be a small fix.
I'm not denying the fact that the change in output might break some programs, but fixing those programs is a one time hassle. Plus let's not assume that *all* the programs/scripts will need the fix, may be some might keep working as before. In any case, I think the greater convenience and utility of information offered by the change to the one and all makes it worth it. Please think about it.
Your convenience is absolutely not reason enough to break those.
Again, it's not just *my* convenience, it'll be more convenient and useful for *everybody*. You know that.
-- Regards - Prasad
Hi,
On Thu, 29 Apr 2010, P J P wrote:
I'm not denying the fact that the change in output might break some programs, but fixing those programs is a one time hassle. Plus let's not assume that *all* the programs/scripts will need the fix, may be some might keep working as before. In any case, I think the greater convenience and utility of information offered by the change to the one and all makes it worth it. Please think about it.
Did you think about it? Still don't find it useful enough??
-- Regards - Prasad
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/02/2010 10:54 PM, P J P wrote:
Did you think about it? Still don't find it useful enough??
Most definitely.
- -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
elfutils-devel@lists.fedorahosted.org