Hi, a long mail with some IRC discussion of the problem.
On Sun, 02 Dec 2007, Bernhard R. Link wrote: > dpkg-shlibdeps misses some symbols and thus prints warnings about not > using symbols from a library even when doing so. [...] > Thus those symbols are actually needed. (They are variables with the > object class of the widget, referencing the actual used methods as > function pointers, thus no other symbols from this library are used). > > | $ objdump -R debian/xbuffy/usr/bin/xbuffy > | debian/xbuffy/usr/bin/xbuffy: file format elf32-sparc > | > | DYNAMIC RELOCATION RECORDS > | OFFSET TYPE VALUE [...] > | 00028a40 R_SPARC_COPY boxWidgetClass [...] > | >From what I can tell, it seems not to be visible with -w -f -p -T: They are visible: > | $ objdump -w -f -p -T debian/xbuffy/usr/bin/xbuffy > | debian/xbuffy/usr/bin/xbuffy: file format elf32-sparc > | architecture: sparc:v8plus, flags 0x00000112: > | EXEC_P, HAS_SYMS, D_PAGED > | start address 0x00011660 [...] > | DYNAMIC SYMBOL TABLE: [...] > | 00028a40 g DO .bss 00000004 boxWidgetClass Except that the symbol is marked as contained in .bss section. Since I didn't know the precise role of that .bss section (documentation says it's for uninitialized data) I asked vorlon: <vorlon> buxy: 454036: definitely a dpkg-dev bug, data symbols should also be part of the list being checked [...] <buxy> the bug log has has the relevant objdump output on the binary <vorlon> right <Q_> The problem being it's a copy relocation? <vorlon> yes, seems so <vorlon> Q_: do you know of any case when there should be an exported symbol in .bss that /isn't/ a copy relocation? <Q_> I have no idea. <vorlon> ok <vorlon> buxy: my guess is that it's reasonable, at least as a next pass, to treat all .bss symbols you find as unresolved symbols <vorlon> if we find exceptions, we can sort those out after : But after some more reseach it appeared that it's not really reasonable: <buxy> vorlon: I don't think I can consider dynamic symbols marked contained in .bss as undefined... <buxy> vorlon: because I see for example on objdump -T /bin/ls: 0805b864 g DO .bss 00000004 GLIBC_2.0 optarg and on libc6: 0011a6bc g DO .bss 00000004 GLIBC_2.0 optarg <buxy> and undefined on both sides doesn't make sense <vorlon> buxy: ah, neat :) <Q_> buxy: In libc6 it also has a relocation: R_X86_64_GLOB_DAT optarg <buxy> Q_: yeah, I was just checking that.... how should I interpret that ? <vorlon> right, so objdump -R and then you have to know which relocs indicate its undefined such as R_386_COPY and R_X86_64_COPY yay arch-specificity <vorlon> meaning what? $ objdump -T -p -m -f -R /lib/libc.so.6 |grep optarg 0014c3c4 g DO .bss 00000004 GLIBC_2.0 optarg 00148fe8 R_386_GLOB_DAT optarg $ that's a dynamic reloc, no? at least, it shows up only under -R <Q_> -R are the dynamic relocs. <buxy> so where is optarg defined ? :) <Q_> GLOB_DAT seems to be saying something about the GOT. <vorlon> buxy: in libc.so.6, I guess... <Q_> But I need to read it a few times before I understand I think. <-- aike est parti (Quit: Leaving) <Q_> buxy: .dynsym also contains an optarg@@GLIBC_2.2.5 <vorlon> seen how? <buxy> .dynsym is -T no ? but I don't see it <Q_> I'm still a bit confused. But it's in .bss yes. I was looking with readelf, which shows: 1243: 000000000035cde0 8 OBJECT GLOBAL DEFAULT 33 optarg@@GLIBC_2.2.5 Where the "33" is .bss So, it's just an unintiliased global variable? <noshadow> Q_: sound reasonable for optarg <buxy> possibly, but what does it mean to have the symbols defined on both sides ? <Q_> And the relocation is just something else that wants to use it. <Q_> buxy: It's a copy relocation, like most variables. <buxy> and how I can differentiate it from the libXaw case where I need to find out that the binary really needs a symbol that comes from libXaw ? <vorlon> because xbuffy has the copy relocation, and libXaw doesn't the copy relocation, AFAIU, is what tells ld.so to go looking for the matching symbol <Q_> What the copy relocation does it copy the pointer in your .bss Since it can't go thru a GOT or simular for it. <buxy> okay, so I should parse -R find symbols with R_*_COPY relocations and consider looking for a corresponding symbol in the libs <vorlon> well, that's my understanding, but I'm not sure how to parse what Q_ said <Q_> buxy: I think you can look at all relocations. <Q_> Hmm, or not. <buxy> Q_: I don't think I can reasonably do that... what does it mean for me to look for optarg while scanning libc6 ? :) <Q_> buxy: I don't understand your last question. <buxy> Q_: currently the symbols like optarg with .bss in objdump -T are considered as defined and are thus output in DEBIAN/symbols files, so it means that I consider that libraries provide them <Q_> I think you should just look for a defined symbol, like you do with the other undefined symbols. <buxy> except that I don't look in the current binary at all <Q_> Oh, in case of a copy relocation it's not defined. <edmonds> awesome: configure.ac: CFLAGS="$CFLAGS -O3" <Q_> It's a copy from what's in a library. <buxy> so you agree that I should handle differently symbols listed in -R depending on the type of relocation ... <Q_> Yes. <buxy> for R_*_COPY i have to look in NEEDED libs to find it out (and it doesn't count whether the symbol is defined in .bss of another library except if the library also has a R_*_COPY relocation on that symbol) <Q_> afaik, mips is the only arch in debian without a copy relocation. <vorlon> indeed, xbuffy/mips shows boxWidgetClass as an ordinary *UND* symbol <Q_> buxy: I think it has too many negations to parse it. <vorlon> so no trouble there <vorlon> buxy: for R_*_COPY you have to look in NEEDED libs to find the symbol's definition, and find the library that has the symbol *without* also having an R_*_COPY relocation of its own <buxy> vorlon: yeah, that's what I meant <vorlon> ok <Q_> vorlon: I think that's what he tried to say. <vorlon> I don't think that's what he actually said, but as long as we all now agree, that's fine ): :) <noshadow> will such a library always have a *_GLOB_DAT or is that just coincidence? <buxy> Q_: is there any point in looking up the other types of relocations? it looks like they all correspond to an *UND* in the objdump -T output <vorlon> noshadow: not always GLOB_DAT <noshadow> vorlon: when is it not? <vorlon> noshadow: when it's R_386_32, for instance <Q_> noshadow: The GLOB_DAT in it is just because the library also uses it. It could have been an other relocation. (Depending on how it's used.) <noshadow> Q_: ah, of course, thanks <buxy> vorlon: this also means that current symbols files might have symbols that they shouldn't have... ie symbols that are R_*_COPY relocated and that fixing this bug might mean build failures due to symbols that disappears :-( <Q_> buxy: I don't think it should result in build failures. <vorlon> Q_: the build failure is because dpkg-gensymbols rightly errors out when a newer version of a lib has dropped symbols found in the symbol file <vorlon> since that implies "ABI breakage" <Q_> Oh, right. <buxy> Q_: is there any point in looking up the other types of relocations? it looks like they all correspond to an *UND* in the objdump -T output (or would a thorough check reveal that my first impression is wrong ?) <Q_> buxy: I have no idea. <Q_> I also think all the others that have a function name with them are undefined. So in the end, I think we'll have to parse objdump -R too and for all symbols that have a R_*_COPY relocations we have to mark the corresponding symbol as undefined. This means that binaries like xbuffy would be considered as having undefined symbols to resolve (ie it would fix this bug). On the other hand, it also means that some packages might have symbols in their symbols file that they are not really exporting since they also correspond to a R_*_COPY relocation. I have no idea if this could be widespread problem. It certainly isn't worrying currently as not many packages provide symbols files. This could change however... Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
