Re: Patch for lsblibchk

On Fri, 24 Jun 2005, Thorsten Kukuk wrote:

>
> Hi,
>
> with this patch, lsblibchk passes on x86. I don't know if the patch
> is really correct, since I don't understand the whole lsblibchk code:
>
> I found out, that classp->vtable[v].virtfuncs[j] is sometimes an empty
> string, dladdr has to fail with it.
>
>  Thorsten
>
> --- classchk.c	16 Jun 2005 18:58:20 -0000	1.46
> +++ classchk.c	24 Jun 2005 07:01:07 -0000
> @@ -222,8 +222,12 @@
> 					 * Look up the name of the symbol associated with the funcptr
> 					 * found in the vtable.
> 					 */
> +					if (classp->vtable[v].virtfuncs[j] == NULL || classp->vtable[v].virtfuncs[j][0] == '\0')
> +					   continue;
> +
> +					symp = dlsym(dlhndl, classp->vtable[v].virtfuncs[j]);
> 					memset(&dlinfo,0,sizeof(dlinfo));
> -					if( !dladdr(fptr2ptr(vtvirtfuncs[j]), &dlinfo) ) {
> +					if( !dladdr(symp, &dlinfo) ) {
> 						fprintf(stderr,"Class %s\n", classp->name );
> 						TETJ_REPORT_INFO("Error looking for symbol for Virtual table entry "
> 														 "[%d][%d](%p) expecting %s\n",

This change completely changes what is being tested. The test is
designed to take an address in the vtable from the object
(vtvirtfuncs[j]), and look up the name which is then compared to 
the expected names fromt he DB (classp->vtable[v].virtfuncs[j]).

This changes causes the test to ignore what is actually found in the
object, and to just make sure that the expected name can be found with
dlsym() and that the result returns tha same name via dladdr().


                                 Stuart

Stuart R. Anderson                               [email protected]
Network & Software Engineering                   http://www.netsweng.com/
1024D/37A79149:                                  0791 D3B8 9A4C 2CDC A31F
                                                  BD03 0A62 E534 37A7 9149