On 2015-08-05, at 5:50 PM, John David Anglin wrote:
> If I was to guess, I would have to think the dladdr call in
> PR_GetLibraryFilePathname_stub fails because
> hppa uses function descriptors for indirect calls. Did this work for ia64?
> There seems to be some trickiness
> there.
Not quite right but close. PR_GetLibraryFilePathname() is actually in
/usr/lib/hppa-linux-gnu/libnspr4.so.
This hunk is used:
#if defined(USE_DLFCN) && defined(HAVE_DLADDR)
Dl_info dli;
char *result;
if (dladdr((void *)addr, &dli) == 0) {
PR_SetError(PR_LIBRARY_NOT_LOADED_ERROR, _MD_ERRNO());
DLLErrorInternal(_MD_ERRNO());
return NULL;
}
result = PR_Malloc(strlen(dli.dli_fname)+1);
if (result != NULL) {
strcpy(result, dli.dli_fname);
}
return result;
PR_GetLibraryFilePathname is passed the following:
Breakpoint 1, 0xfc4e09d4 in PORT_LoadLibraryFromOrigin ()
from debian/libnss3/usr/lib/hppa-linux-gnu/libnssutil3.so
(gdb) p/x $r25
$11 = 0x173f2
(gdb) p (char *)$r26
$12 = 0x15ff0 "libnssutil3.so"
$r5 contains a function pointer pointing to a function descriptor:
(gdb) x/2x 0x173f0
0x173f0: 0x0001756c 0x0000000c
0x0001756c is the address of a stub:
(gdb) disass 0x0001756c,0x0001756c+8
Dump of assembler code from 0x1756c to 0x17574:
0x0001756c: b,l 0x17560,r20
0x00017570: depwi 0,31,2,r20
On return from dladdr, dli contains:
Breakpoint 5, 0xfc6bd74c in PR_GetLibraryFilePathname ()
from /usr/lib/hppa-linux-gnu/libnspr4.so
(gdb) p/x $sp-0x78
$8 = 0xfd703a08
(gdb) x/4x 0xfd703a08
0xfd703a08: 0xfd7016e1 0x00010000 0x00000000 0x00000000
(gdb) p (char *)0xfd7016e1
$9 = 0xfd7016e1
"/home/dave/debian/nss/nss-3.19.2/debian/libnss3-tools/usr/bin/shlibsign"
Thus, dladdr doesn't correctly handle function pointers on hppa. On the other
hand, it's
not clear how dladdr can tell the difference between a data pointer and a
function pointer.
Dave
--
John David Anglin [email protected]
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
