Pourquoi un symbole ne serait-il pas recherché sur le binaire lui-même?

Question

J'ai changé un binaire ELF, et maintenant j'essaie de savoir ce que j'ai gâché. Mon binaire instrumenté est appelé mutatee_out sur le texte collé ci-dessous. Le symbole qu'il dit qui n'est pas défini est en effet dans la table dynamique, j'ai vérifié. Et aussi avec la bonne adresse sur la section .text. Donc, ma question est: quelles sont les raisons d'un symbole indéfini? (Donc je peux examiner ce qui aurait pu aller mal).

Lorsque j'ai couru avec LD_DEBUG=symbols, j'ai remarqué qu'il ne cherche pas ce symbole dans le fichier lui-même, d'où le symbole indéfini. Les autres symboles sont recherchés sur le fichier comme vous pouvez le voir ci-dessous aussi.

Des idées? Pourquoi ce symbole ne serait-il pas recherché sur le binaire lui-même?

17405:  symbol=_ZTVSt11regex_error; lookup in file=mutatee_out [0] 
17405:  symbol=_ZTVSt11regex_error; lookup in file=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 [0] 
17405:  symbol=__gxx_personality_v0; lookup in file=mutatee_out [0] 
17405:  symbol=_ZN9__gnu_cxx27__verbose_terminate_handlerEv; lookup in file=mutatee_out [0] 
17405:  symbol=_ZN9__gnu_cxx27__verbose_terminate_handlerEv; lookup in file=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 [0] 
17405:  symbol=_ZSt9terminatev; lookup in file=mutatee_out [0] 
17405:  symbol=_ZSt9terminatev; lookup in file=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 [0] 
17405:  symbol=__gmon_start__; lookup in file=mutatee_out [0] 
17405:  symbol=__gmon_start__; lookup in file=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 [0] 
17405:  symbol=__gmon_start__; lookup in file=/lib/x86_64-linux-gnu/libgcc_s.so.1 [0] 
17405:  symbol=__gmon_start__; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0] 
17405:  symbol=__gmon_start__; lookup in file=/lib/x86_64-linux-gnu/libm.so.6 [0] 
17405:  symbol=__gmon_start__; lookup in file=/lib64/ld-linux-x86-64.so.2 [0] 
17405:  symbol=__gmon_start__; lookup in file=/lib/x86_64-linux-gnu/libdl.so.2 [0] 
17405:  symbol=_ZN9decl_test8call_cppEi; lookup in file=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 [0] 
17405:  symbol=_ZN9decl_test8call_cppEi; lookup in file=/lib/x86_64-linux-gnu/libgcc_s.so.1 [0] 
17405:  symbol=_ZN9decl_test8call_cppEi; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0] 
17405:  symbol=_ZN9decl_test8call_cppEi; lookup in file=/lib/x86_64-linux-gnu/libm.so.6 [0] 
17405:  symbol=_ZN9decl_test8call_cppEi; lookup in file=/lib64/ld-linux-x86-64.so.2 [0] 
17405:  symbol=_ZN9decl_test8call_cppEi; lookup in file=/lib/x86_64-linux-gnu/libdl.so.2 [0] 
17405:  mutatee_out: error: symbol lookup error: undefined symbol: _ZN9decl_test8call_cppEi (fatal) 

Answer 1

Quelles parties du binaire avez-vous modifiées? Juste .dynsym? Ou .gnu.hash aussi bien? Si la table de hachage n'est pas synchronisée, ld.so ne trouvera pas de symboles.

Answer 2

Pourquoi ce symbole ne serait-il pas recherché sur le binaire lui-même?

Peut-être le binaire demandéld.so de ne pas rechercher dans le binaire lui-même?

Il pourrait le faire avec:

void *sym = dlsym(RTLD_NEXT, "_ZN9decl_test8call_cppEi"); 

Je parse l'ensemble binaire et le réécrire à nouveau.

Il est extrêmement difficile de réaliser une telle transformation correctement sur un binaire déjà lié.

Mais je crois que certaines analyses naines peuvent être fausses ou l'écriture de la section .eh_frame peut être fausse.

Aucun des ci-dessus a rien à voir avec la résolution des symboles.

Je vais vérifier le hachage gnu bien.

non de construire la table de hachage entraînerait un échec de recherche, mais dans votre cas ld.so est même pas la recherche, de sorte que la cause doit être autre chose.