Re: Patch for lsblibchk

On Fri, Jun 24, Stuart Anderson wrote:

> 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]).

The problem is that it makes assumptions about internals, which seems
are no longer true.

  Thorsten

-- 
Thorsten Kukuk         http://www.suse.de/~kukuk/      [email protected]
SUSE LINUX Products GmbH       Maxfeldstr. 5       D-90409 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B