re: CVS commit: src/lib/librumphijack
> > cvs rdiff -u -r1.7 -r1.8 src/lib/librumphijack/Makefile
> > cvs rdiff -u -r1.1 -r1.2 src/lib/librumphijack/hijackdlsym.c
>
> I think this is caused by revision 1.121 of rtld.c (hi, mac!) that
> added "hackish_return_address" for ppc.
>
> #ifdef __powerpc__
> static void *
> hackish_return_address(void)
> {
> return __builtin_return_address(1);
> }
> #endif
>
> void *
> dlsym(void *handle, const char *name)
> {
> ...
> #ifdef __powerpc__
> retaddr = hackish_return_address();
> #else
> retaddr = __builtin_return_address(0);
> #endif
> ...
> }
>
>
> hackish_return_address will be inlined (simple static function) and,
> as far as I can tell, gcc does NOT adjust the "level" argument to
> __builtin_return_address.
>
> The net effect is that dlsym uses caller's caller address to detect
> which module the call comes from, and if caller's caller is in a
> different module wrong things happen.
>
> That explains why you need an extra frame.
ugh!
mac, what wasn't working that prompted you to do the above?
one hack to make it work would be to apply the noinline
gcc attribute
.mrg.
Re: CVS commit: src/lib/librumphijack
On Sun, Feb 27, 2011 at 08:12:37 +0300, Valeriy E. Ushakov wrote:
> On Fri, Feb 25, 2011 at 16:01:42 +, Antti Kantee wrote:
>
> > Module Name:src
> > Committed By: pooka
> > Date: Fri Feb 25 16:01:42 UTC 2011
> >
> > Modified Files:
> > src/lib/librumphijack: Makefile hijackdlsym.c
> >
> > Log Message:
> > Ok, for reasons I can't begin to understand, the binaries I tested
> > yesterday on powerpc broke overnight. Apparently adding one more
> > function before the call to dlsym() fixes things again. I hope
> > I don't have to add another one tomorrow
> >
> >
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.7 -r1.8 src/lib/librumphijack/Makefile
> > cvs rdiff -u -r1.1 -r1.2 src/lib/librumphijack/hijackdlsym.c
>
> I think this is caused by revision 1.121 of rtld.c (hi, mac!) that
> added "hackish_return_address" for ppc.
>
> #ifdef __powerpc__
> static void *
> hackish_return_address(void)
> {
> return __builtin_return_address(1);
> }
> #endif
>
> void *
> dlsym(void *handle, const char *name)
> {
> ...
> #ifdef __powerpc__
> retaddr = hackish_return_address();
> #else
> retaddr = __builtin_return_address(0);
> #endif
> ...
> }
>
>
> hackish_return_address will be inlined (simple static function) and,
> as far as I can tell, gcc does NOT adjust the "level" argument to
> __builtin_return_address.
>
> The net effect is that dlsym uses caller's caller address to detect
> which module the call comes from, and if caller's caller is in a
> different module wrong things happen.
>
> That explains why you need an extra frame.
Actually, the real reason behind PR 37812 (that was supposed to be
fixed by the hackish_return_address) might be similar to the issue
with rumphijack_dlsym.
If I read xorg-server/dist/hw/xfree86/loader correctly, you probably
end up with dlsym being tail-called. My knowledge of ppc asm/abi is
zero, so I can't really tell what goes on there or what went wrong in
the original scenario, but I'd guess your hackish return gets inlined
and with dlsym in tail-call position your caller's caller (unadjusted
level "1") is in the main program and then luck is on your side,
unless you do e.g. RTLD_NEXT.
PS: this probably calls for some atf tests for dlsym &co.
-uwe
Re: CVS commit: src/lib/librumphijack
On Fri, Feb 25, 2011 at 16:01:42 +, Antti Kantee wrote:
> Module Name: src
> Committed By: pooka
> Date: Fri Feb 25 16:01:42 UTC 2011
>
> Modified Files:
> src/lib/librumphijack: Makefile hijackdlsym.c
>
> Log Message:
> Ok, for reasons I can't begin to understand, the binaries I tested
> yesterday on powerpc broke overnight. Apparently adding one more
> function before the call to dlsym() fixes things again. I hope
> I don't have to add another one tomorrow
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.7 -r1.8 src/lib/librumphijack/Makefile
> cvs rdiff -u -r1.1 -r1.2 src/lib/librumphijack/hijackdlsym.c
I think this is caused by revision 1.121 of rtld.c (hi, mac!) that
added "hackish_return_address" for ppc.
#ifdef __powerpc__
static void *
hackish_return_address(void)
{
return __builtin_return_address(1);
}
#endif
void *
dlsym(void *handle, const char *name)
{
...
#ifdef __powerpc__
retaddr = hackish_return_address();
#else
retaddr = __builtin_return_address(0);
#endif
...
}
hackish_return_address will be inlined (simple static function) and,
as far as I can tell, gcc does NOT adjust the "level" argument to
__builtin_return_address.
The net effect is that dlsym uses caller's caller address to detect
which module the call comes from, and if caller's caller is in a
different module wrong things happen.
That explains why you need an extra frame.
-uwe
re: device major numbers
> On Sat, 26 Feb 2011, Frank Wille wrote: > > Modified Files: > > src/etc/etc.sandpoint: MAKEDEV.conf > > src/sys/arch/sandpoint/conf: files.sandpoint > > > > Log Message: > > Changed satmgr(4) device major number from 100 to 144, which is reserved > > for local/vendor use according to src/sys/conf/majors. This prevents > > problems when the shared PowerPC device majors list gets another entry. > > I thought that "Majors 144-159 are reserved for local/vendor use" meant > "Device drivers that are part of NetBSD will not use major numbers 144 > to 159; those numbers may be used by end users or third party vendors > who add custom device drivers to systems bsed on NetBSD." since satmgr(4) is sandpoint specific, it very much does not belong in the 144-159 range. why does it need to be changed? this meanst hat new kernels with an older userland won't work with satmgr at all. can the 100 value be reserved in other ppc majors, or it just moved to a generic major? either way, 144 is wrong. .mrg.
re: CVS commit: src/gnu/dist/gcc4/gcc/config/rs6000
> Module Name: src > Committed By: matt > Date: Fri Feb 25 22:36:10 UTC 2011 > > Modified Files: > src/gnu/dist/gcc4/gcc/config/rs6000: netbsd.h > > Log Message: > Explicitly make sure TARGET_SECURE_PLT is defined correctly rather than > relying on HAVE_AS_REL16 from "auto-host.h". please add a doc/HACKS entry for this, and perhaps add a comment to netbsd.h itself that this change should not be sent upstream or ported back to prior releases. thanks. .mrg.
device major numbers
On Sat, 26 Feb 2011, Frank Wille wrote: > Modified Files: > src/etc/etc.sandpoint: MAKEDEV.conf > src/sys/arch/sandpoint/conf: files.sandpoint > > Log Message: > Changed satmgr(4) device major number from 100 to 144, which is reserved > for local/vendor use according to src/sys/conf/majors. This prevents > problems when the shared PowerPC device majors list gets another entry. I thought that "Majors 144-159 are reserved for local/vendor use" meant "Device drivers that are part of NetBSD will not use major numbers 144 to 159; those numbers may be used by end users or third party vendors who add custom device drivers to systems bsed on NetBSD." --apb (Alan Barrett)
Re: CVS commit: src
On Sat, Feb 26, 2011 at 11:09:21 +0200, Antti Kantee wrote: > ( is probably gdb's imagination, though) It's probably not. Syscall error handling code comes before the syscall code, so the nearset preceding label is that of the previous syscall. So that fcntl+21 is really code for execve (next alphabetically). -uwe
Re: CVS commit: src
On Fri Feb 25 2011 at 22:06:32 +0100, Joerg Sonnenberger wrote: > On Fri, Feb 25, 2011 at 04:38:54PM +0200, Antti Kantee wrote: > > On Fri Feb 25 2011 at 15:19:30 +0100, Joerg Sonnenberger wrote: > > > I get time outs for stress_long and stress_short (rump/rumpkern/t_sp). > > > > Those are because of, from what I could tell, this: > > > > 0xbbbd45c5 : mov%gs:0x0,%edi > > ==> segfault > > > > Notably, those tests exercise threads and processes more heavily than > > any other test we have: they create 256 concurrent racing threads over > > several processes which are killed and recreated. > > Are you sure about that? libpthread should be the only thing (before the > back out) that touches %gs and the kernel is normally using %fs for CPU > local memory. I'm sure as in "run test, see h_stresscli crash, gdb core, x/i $eip". I didn't examine it any further. The test fails with the lwp fastreg stuff and doesn't fail without it, that i am sure it. ( is probably gdb's imagination, though) -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
