On Sep 11, 2012, at 11:19 PM, Emmanuel Dreyfus wrote:
> Matt Thomas wrote:
>
>> Only those ports which reserve a register in mcontext for the TCB
>> pointer should define _UC_TLSBASE. Otherwise _UC_TLSBASE has no
>> meaning and thus should not be defined.
>
> Well, we have the choice between:
Matt Thomas wrote:
> Only those ports which reserve a register in mcontext for the TCB
> pointer should define _UC_TLSBASE. Otherwise _UC_TLSBASE has no
> meaning and thus should not be defined.
Well, we have the choice between:
- define it and keeep it unused
- not define it add add #ifdef in
On Sep 11, 2012, at 7:00 PM, Emmanuel Dreyfus wrote:
>
> - add _UC_TLSBASE definition in header file for all ports
> (powerpc, sh3, sparc and sparc64 lack the implementation for now)
Only those ports which reserve a register in mcontext for the TCB
pointer should define _UC_TLSBASE. Otherwise
hello. It turns out this problem ismore sinister than I first
thought. I have another such binary that hangs the system entirely -- even
running ldd(1), which I assume runs through the same bad code causes the
system to become completely unresponsive -- no ping, no shell control-t,
hard r
You are looking for the
for (i = 0; i < nexecs; i++) {
(starting at line 377 of sys/kern_exec.c in my -5 tree)
Especially check if exec_aout.c:exec_aout_makecmds() is invoked and
what error it returns, maybe some other exec package eroneously claims
it first?
Martin
On Mon, Sep 10, 2012 at 03:20:34PM -0700, Brian Buhrow wrote:
> hello. I have a server which was, up until yesterday, running
> NetBSD-4.0-stable. After I updated it to NetBSD-5.1 with sources from July
> 18 2012, I find my binaries from NetBSD-0.9A no longer run. The problem
> seems to be
