>> Should you really be testing VM_READ|VM_WRITE, or should it just
>> be VM_READ?
>
> We test VM_READ | VM_WRITE | VM_EXEC in the read case below, and that
> is because we have no HPTE encoding to say "writable but not readable"
> or "executable but not readable". Similarly we have no encoding to
Segher Boessenkool writes:
> Should you really be testing VM_READ|VM_WRITE, or should it just
> be VM_READ?
We test VM_READ | VM_WRITE | VM_EXEC in the read case below, and that
is because we have no HPTE encoding to say "writable but not readable"
or "executable but not readable". Similarly we
On Jul 19, 2007, at 2:10 PM, Jon Loeliger wrote:
> On Thu, 2007-07-19 at 14:02, Scott Wood wrote:
>
>> glib != glibc.
>>
>> -Scott
>
> D'oh.
>
> So, It doesn't say what version it is.
> But it is also dated 8-Apr-2003.
The glibc jdl tested against is 2.2.5.
- k
_
On Thu, 2007-07-19 at 14:02, Scott Wood wrote:
> glib != glibc.
>
> -Scott
D'oh.
So, It doesn't say what version it is.
But it is also dated 8-Apr-2003.
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/l
On Thu, Jul 19, 2007 at 01:57:00PM -0500, Jon Loeliger wrote:
> Needless to say, one that showed the problem beforehand. :-)
> But to be precise:
>
> [root:~] ls -lsa /usr/lib/libglib*
>0 lrwxrwxrwx1 18005314 24012 21 Aug 15 2005
> /usr/lib/libglib-1.2.so.0 -> libglib-1.2.so.0.0
On Thu, 2007-07-19 at 12:16, Segher Boessenkool wrote:
> > Tested on 8641HPCN.
>
> Which glibc versions? glibc-2.4 and newer are fine without the
> patch already, glibc-2.3 seems to get away by accident; but 2.2
> (and before) are the problematic ones.
>
> No other userland program has been ide
> Hmmm. The dangling else clauses are pretty gross,
I hoped you wouldn't notice. I guess I shouldn't have
commented them :-)
"It was the cleanest thing I could come up with". Every
other thing I tried ended up as a maze of #ifdefs or some
incomprehensible cross-jumping mess; and I was aiming f
>> Hmmm. The dangling else clauses are pretty gross, and in fact we
>> have
>> the same problem on POWER3 and RS64 processors (to be fair, we had
>> the problem before and didn't notice, but we should still fix it).
>>
>> How about this instead? Could people test it please? (Note that
>> CPU_F
On Wed, 2007-07-18 at 19:00, Paul Mackerras wrote:
> Hmmm. The dangling else clauses are pretty gross, and in fact we have
> the same problem on POWER3 and RS64 processors (to be fair, we had
> the problem before and didn't notice, but we should still fix it).
>
> How about this instead? Could
Segher Boessenkool writes:
> Some old software on ppc32 executes from pages it hasn't marked
> executable. Since "classic" hardware doesn't distinguish between
> execute and read accesses, the do_page_fault() code shouldn't
> either. This makes glibc-2.2 work again on such hardware.
>
> Signed-
On Wed, 2007-07-11 at 20:18 +0200, Segher Boessenkool wrote:
> Some old software on ppc32 executes from pages it hasn't marked
> executable. Since "classic" hardware doesn't distinguish between
> execute and read accesses, the do_page_fault() code shouldn't
> either. This makes glibc-2.2 work aga
11 matches
Mail list logo
