Bug#604047: warning: collect info objdump-info about package PACKAGE failed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-01-17 21:45, Russ Allbery wrote:
> Niels Thykier <niels@thykier.net> writes:
>
>> objdump -T --headers --private-headers looks the same as well in both
>> cases (but it still exits 1 in experimental). Removing the -T will make
>> it succeed and I found the following entry in the upstream changelog:
>
>> 2010-10-05 Alan Modra <amodra@gmail.com>
>
>> [...]
>> * objdump.c (free_only_list): Formatting.
>> (slurp_dynamic_symtab): Non-zero exit status for "not a dynamic
>> object".
>> [...]
>> (main): Return non-zero exit status on bad options.
>> [...]
>
>> I guess objdump has become a bit more strict with its exit codes :)
>
> Ideally we'd finish the work required to just switch to readelf. I think
> last time we looked at that we concluded we could get all of the same
> information. objdump is theoretically superior in that it can also handle
> non-ELF binaries, but it seems unlikely to me that Debian is ever going to
> have a non-ELF architecture. And IIRC readelf doesn't care about
> differing word sizes, architectures, and so forth the way that objdump
> tends to.
>
Okay, what exactly is it we need? I looked around and it looks like we
need:
* SONAME
- package name check and such
* NEEDED
- debug tags, static linking and not linked against libc.
* KLIBC
- Exception to static linking tags.
* symbols (all of them? can we skip undefined ones?)
- We look for '_mcount' in "GLIBC_", so I am guessing no?
- We also look for exit/fork
* sections (at least .note and .comment)
- incomplete stripping
* RPATH
- on usr/lib/
* "TEXTREL"
- "non-pic" in SO
* "INTERP"
- Exception to shlib with executable marker.
* CXXABI (is that a marker of a C++ lib/program?)
- also not sure why - no check seems to be using it.
* Some "STACK" stuff
- checks for lacking PT_GNU_STACK and executable
stacks.
* UPX compression (which comes from "head $bin" >.>)
- Also a tag
We do not compare the symbols read from the SO to match it against the
symbols file as far as I can tell. Perhaps we could use the opportunity
to implement that as well? We can use --wide plus a c++filt pipe to
demangle the symbols.
Okay - as I see it; we need to map section numbers for when we parse the
symbols table. objdump did that for us, but readelf leaves us either
UND (I am guessing short for UNDEFINED), ABS (not sure, but I am
guessing "core symbols"[1]) and then a number I believe match an section
number (as printed by --section-headers).
For my i386 /bin/ls this means it has symbols in the sections:
.bss - stdout, __progname, program_invocation_name
.rodata - _IO_stdin_used
.fini - _fini
.init - _init
For other programs/shared library I also saw symbols in .text. So I am
guessing that makes sense (but feel free to correct me if you happen to
know I am wrong).
I think we can see the presence of the PT_GNU_STACK in the program
headers (--program-headers), where it has an entry called "GNU_STACK".
The "E" in the "Flg" column could mean executable, so that part should
not be too difficult to re-generate either (possible exception is how is
a non-GNU stack printed - just as STACK?).
SONAME, NEEDED, TEXTREL and INTERP are probably in the --dynamic table
(the two former are, but I have not seen an example with the two latter
- - maybe I will have a look at the libbaz test later :P )
I have seen stuff like this in the symbols table:
(mangled) _ZTVN10__cxxabiv117__class_type_infoE@CXXABI_1.3
vtable for __cxxabiv1::__vmi_class_type_info@CXXABI_1.3 (5)
Is this the CXXABI we are looking for with objdump (or can it be used
for our purpose)?
~Niels
[1] Symbol names include _end, _edata and __bss_start in /bin/ls.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNNiF8AAoJEAVLu599gGRChCsQAJonXasQczPGNDonlbGBxTeH
SXFoAQeWzKpQrvlYh5XtyfG8VpnO0BzUebJTFU/7ExdUuRjwsrhz6xGY1sykB3xa
fFwPEVwsXSHEg8OMjQrEaDqCbOuFBoW7bc2hVrRnefMsVbFxB39GNW+SE/DVPHzd
9Tbxp2gNfBTj8bamb2fajhcBCrMpCUIk6tt7EP/neuiNkxDrrWrs9iT5jZwmit1M
gDZh1IysQnQ7p6WjOfDP1/cP4w/UE9R515fLVwrB27F/qGwLW3A8I+GOslRafI3n
oV9dczql60jP/Es+izYwLdCsWYgg0q2MFMRj3m9DmgG4CFY9SBYt7ZyjwS+RoBvB
g42XxXZqPkhu4mKxqepM9w6W0Dl6qQsenl6DM189YnNSGy+ZBDSa9ifrYkInrfL2
uDQfRC+jXi2JDnNqL5cgawf13vXcQ74UT0ryGzDfud9DnYriu8+iR2qW2504CFzn
4max178XLM9rBHeFvwPDT9IhmHMs38GCz/7ylIQrdgrzM3qJThn2g1EBUlL/JHYc
CnFIeisMd/h7HEvozgaQQqnNA0HYDm5kE6QM8/mP+FxDAFMOPpIXWt0umBJoRkUr
r3f14bVJ/xEqJ+tx+GZj05HjCvA9G7I0IhJOxuN9aWlUpeh7eZRupV3jFn/v9yJ5
p6COo6Ud0V4zFj542mRC
=XzTM
-----END PGP SIGNATURE-----
Reply to: