valgrind dla softów linkowanych dynamicznie

0

Witam
Czy da się zrobić tak by valgrind nie pokazywał segmentation faultów od linkera dynamicznego dla softu który jest linkowany dynamicznie czyli uruchamiany w linuxie za pomocą linkera dynamicznego ld?
Powiem tyle że nie pomaga stworzenie suppression pliku. Tzn. najpierw uruchamiamy valgrinda na sofcie z opcja --gen-suppressions=all po czym valgrind wygeneruje nam w xmlu m.in. wstawki jakie nalezy umieścić w suppression pliku by ignorował te warningi. Przy nastepnych uruchomieniu valgrinda podajemy flagę --suppressions z nazwa pliku. W ten sposób warningi niektóre są ignorowane ale to i tak nie pomaga bo dalej sa segmentation faulty spowodowane przez linkera dynamicznego, poza tym niektóre warningu też są pomimo że podaliśmy we fladze suppressions plik. Więc czyżby stąd wniosek że valgrind to tool który nie nadaje się do softów linkowanych dynamicznie? Używanie valgrinda z tymi errorami mija się z celem, bo nie wyobrażam sobie by za każdym razem przeglądać logi warningowe by się upewniac czy to na 100% błąd nie jest spodowowany przez moją modyfikację i jest to spowodane przez linker.

0

Do tego wyżej dodam tyle że jestem pewny że valgrindy nie są spowodane przez mój kod bo valgrind wypluwa output typu:

29: ==12399== Conditional jump or move depends on uninitialised value(s)
29: ==12399==    at 0x120BD4: index (strchr.S:77)
29: ==12399==    by 0x10F7C2: expand_dynamic_string_token (dl-load.c:370)
29: ==12399==    by 0x110430: _dl_map_object (dl-load.c:2119)
29: ==12399==    by 0x108E24: map_doit (rtld.c:485)
29: ==12399==    by 0x117093: _dl_catch_error (dl-error.c:187)
29: ==12399==    by 0x108A8E: do_preload (rtld.c:668)
29: ==12399==    by 0x10B441: dl_main (rtld.c:1504)
29: ==12399==    by 0x11ED6F: _dl_sysdep_start (dl-sysdep.c:249)
29: ==12399==    by 0x10CC49: _dl_start (rtld.c:309)
29: ==12399==    by 0x108C47: ??? (in /var/fpwork/userSome/projekt/host-64/tmp/sysroots/host-64/lib/ld-2.22.so)
29: ==12399==    by 0x3: ???
29: ==12399==    by 0x7FEFFF5FE: ???
29: ==12399==  Uninitialised value was created by a stack allocation
29: ==12399==    at 0x10B3CF: dl_main (rtld.c:1494)
29: ==12399==
29: vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x1B 0x4 0x24 0x66 0xF 0x1B
29: vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
29: vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
29: vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
29: ==12399== valgrind: Unrecognised instruction at address 0x11cef7.
29: ==12399==    at 0x11CEF7: _dl_runtime_resolve (dl-trampoline.S:78)
29: ==12399==    by 0x6AD4AC8: __exp_finite (e_exp.c:16)
29: ==12399==    by 0x11368F: _dl_relocate_object (dl-machine.h:534)
29: ==12399==    by 0x10BDE2: dl_main (rtld.c:2075)
29: ==12399==    by 0x11ED6F: _dl_sysdep_start (dl-sysdep.c:249)
29: ==12399==    by 0x10CC49: _dl_start (rtld.c:309)
29: ==12399==    by 0x108C47: ??? (in /var/fpwork/userSome/projekt/host-64/tmp/sysroots/host-64/lib/ld-2.22.so)
29: ==12399==    by 0x3: ???
29: ==12399==    by 0x7FEFFF5FE: ???
29: ==12399==    by 0x7FEFFF64F: ???
29: ==12399==    by 0x7FEFFF65E: ???
29: ==12399==    by 0x7FEFFF6DA: ???
29: ==12399== Your program just tried to execute an instruction that Valgrind
29: ==12399== did not recognise.  There are two possible reasons for this.
29: ==12399== 1. Your program has a bug and erroneously jumped to a non-code
29: ==12399==    location.  If you are running Memcheck and you just saw a
29: ==12399==    warning about a bad jump, it's probably your program's fault.
29: ==12399== 2. The instruction is legitimate but Valgrind doesn't handle it,
29: ==12399==    i.e. it's Valgrind's fault.  If you think this is the case or
29: ==12399==    you are not sure, please let us know and we'll try to fix it.
29: ==12399== Either way, Valgrind will now raise a SIGILL signal which will
29: ==12399== probably kill your program.

Nie generuje się już w xmlu wstawka suppression dla powyższego jaką można by wstawić jeszcze do .supp pliku pomimo opcji --gen-suppressions=all. Poza tym nawet jakby się wygenerowała to przecież i tak pewnie będzie segmentation fault a jedynie outputu odnosnie warninga byśmy nie mieli na konsoli. Coś czuje że ten program nie nadaje sie do takiej dynamicznie linkowanej aplikacji.

1 użytkowników online, w tym zalogowanych: 0, gości: 1