|
From: Paul M. <pa...@sa...> - 2006-07-02 22:40:58
|
It's possible to configure 64-bit PowerPC kernels with a 64kB page
size rather than the usual 4kB page size. That means that mmap
offsets, etc., need to be a multiple of 64k when running on such a
kernel. The ABI allows this and requires programs to get the page
size from the system (e.g. with getpagesize(), sysconf(), or by
looking at the AT_PAGESIZE aux table entry), rather than assuming a
hardcoded value.
At the moment we hardcode VKI_PAGE_SHIFT to 12 in
include/vki-ppc{32,64}-linux.h. There are only two places I can see
where we use VKI_PAGE_SIZE as an array dimension, both in
coregrind/m_ume.c. So it should be possible to make VKI_PAGE_SIZE and
VKI_PAGE_SHIFT be variables for ppc32 and ppc64.
A related potential gotcha is that the offset parameter to sys_mmap2
is always (byte_offset >> 12) rather than (byte_offset / PAGE_SIZE).
The PRE(sys_mmap2) code is OK as it stands but will need to be changed
if we make VKI_PAGE_SIZE a variable.
Paul.
|
|
From: Julian S. <js...@ac...> - 2006-07-03 11:05:54
|
Is it more appropriate to make VKI_PAGE_SIZE/SHIFT variables, or
constants which are detected by the configure script? In the latter
case the launcher can check using sysconf() that the page size is
the same as at build time.
Do you have a patch? We have various ppc-linux boxes available, but
none running a 64k-page kernel afaik, so no obvious test/integration
platform.
J
On Sunday 02 July 2006 23:38, Paul Mackerras wrote:
> It's possible to configure 64-bit PowerPC kernels with a 64kB page
> size rather than the usual 4kB page size. That means that mmap
> offsets, etc., need to be a multiple of 64k when running on such a
> kernel. The ABI allows this and requires programs to get the page
> size from the system (e.g. with getpagesize(), sysconf(), or by
> looking at the AT_PAGESIZE aux table entry), rather than assuming a
> hardcoded value.
>
> At the moment we hardcode VKI_PAGE_SHIFT to 12 in
> include/vki-ppc{32,64}-linux.h. There are only two places I can see
> where we use VKI_PAGE_SIZE as an array dimension, both in
> coregrind/m_ume.c. So it should be possible to make VKI_PAGE_SIZE and
> VKI_PAGE_SHIFT be variables for ppc32 and ppc64.
>
> A related potential gotcha is that the offset parameter to sys_mmap2
> is always (byte_offset >> 12) rather than (byte_offset / PAGE_SIZE).
> The PRE(sys_mmap2) code is OK as it stands but will need to be changed
> if we make VKI_PAGE_SIZE a variable.
>
> Paul.
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Paul M. <pa...@sa...> - 2006-07-07 00:23:08
|
Julian Seward writes: > Is it more appropriate to make VKI_PAGE_SIZE/SHIFT variables, or > constants which are detected by the configure script? In the latter > case the launcher can check using sysconf() that the page size is > the same as at build time. Do you mean that the build process would build and install two versions of everything, one for 4k pages and one for 64k pages, and the launcher would choose one or the other at runtime? That would be OK, I guess, but it seems like a lot more work than making the page size/shift be variables. > Do you have a patch? We have various ppc-linux boxes available, but > none running a 64k-page kernel afaik, so no obvious test/integration > platform. No, I don't have a patch, sorry, and I'll be travelling for the next 3 weeks. Paul. |
|
From: Julian S. <js...@ac...> - 2006-07-09 12:23:18
|
> > Is it more appropriate to make VKI_PAGE_SIZE/SHIFT variables, or > > constants which are detected by the configure script? In the latter > > case the launcher can check using sysconf() that the page size is > > the same as at build time. > > Do you mean that the build process would build and install two > versions of everything, one for 4k pages and one for 64k pages, and > the launcher would choose one or the other at runtime? That would be > OK, I guess, but it seems like a lot more work than making the page > size/shift be variables. Hmm. That does sound somewhat suboptimal. A variable it is then. J |
|
From: Dave N. <dc...@us...> - 2006-10-12 17:59:22
|
Hi Paul,
I went looking for that e-mail that you sent me that suggested that I look in
the auxiliary table for AT_PAGESIZE, and I found this earlier posting. This
posting addresses the problem that I'm trying to solve.
Steve Munroe pointed out that pagesize needs to be computed at run time because
the valgrind executables in a LDP release need to be able to handle both 4K and
64K pagesizes.
I changed VKI_PAGE_SHIFT to be a variable and initialized it in m_main.c/main()
(by looking through the auxiliary table as you suggested) before the first use
in the call to VG_(am_startup).
include/vki-ppc{32,64}-linux.h:
/* PAGE_SHIFT determines the page size. On RHEL5 allows 64K page size */
long __vki_page_shift;
#define VKI_PAGE_SHIFT __vki_page_shift
#define VKI_PAGE_SIZE (1UL << VKI_PAGE_SHIFT)
This works for a little bit but then dies with:
found AT_PAGESZ:pagesize ==10000
setting pagesize:pagesize ==10000, page_shift=16
==7890== Memcheck, a memory error detector.
==7890== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==7890== Using LibVEX rev 1606, a library for dynamic binary translation.
==7890== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==7890== Using valgrind-3.2.0, a dynamic binary instrumentation framework.
==7890== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==7890== For more details, rerun with: -v
==7890==
--7890:0:aspacem Valgrind: FATAL: aspacem assertion failed:
--7890:0:aspacem VG_IS_PAGE_ALIGNED(szB)
--7890:0:aspacem at m_aspacemgr/aspacemgr.c:3027 (vgPlain_am_alloc_VgStack)
I tracked this down to the #defines in coregrind/pub_core_aspacemgr.h:
#define VG_STACK_GUARD_SZB 8192 // 2 pages
#define VG_STACK_ACTIVE_SZB 65536 // 16 pages
typedef
struct {
HChar bytes[VG_STACK_GUARD_SZB
+ VG_STACK_ACTIVE_SZB
+ VG_STACK_GUARD_SZB];
}
VgStack;
I wonder if there are other places in the code that assume pagesize=4K?
I can't just change the #defines to be 2*VKI_PAGE_SIZE/16*VKI_PAGE_SIZE because
they are now dynamic.
At this point I think it is going to take someone with more intimate
understanding of the workings of Valgrind to get this to work.
Any suggestions on how to proceed?
Paul Mackerras wrote:
> It's possible to configure 64-bit PowerPC kernels with a 64kB page
> size rather than the usual 4kB page size. That means that mmap
> offsets, etc., need to be a multiple of 64k when running on such a
> kernel. The ABI allows this and requires programs to get the page
> size from the system (e.g. with getpagesize(), sysconf(), or by
> looking at the AT_PAGESIZE aux table entry), rather than assuming a
> hardcoded value.
>
> At the moment we hardcode VKI_PAGE_SHIFT to 12 in
> include/vki-ppc{32,64}-linux.h. There are only two places I can see
> where we use VKI_PAGE_SIZE as an array dimension, both in
> coregrind/m_ume.c. So it should be possible to make VKI_PAGE_SIZE and
> VKI_PAGE_SHIFT be variables for ppc32 and ppc64.
>
> A related potential gotcha is that the offset parameter to sys_mmap2
> is always (byte_offset >> 12) rather than (byte_offset / PAGE_SIZE).
> The PRE(sys_mmap2) code is OK as it stands but will need to be changed
> if we make VKI_PAGE_SIZE a variable.
>
> Paul.
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Nicholas N. <nj...@cs...> - 2006-10-12 22:57:49
|
On Thu, 12 Oct 2006, Dave Nomura wrote:
> I went looking for that e-mail that you sent me that suggested that I look in
> the auxiliary table for AT_PAGESIZE, and I found this earlier posting. This
> posting addresses the problem that I'm trying to solve.
>
> Steve Munroe pointed out that pagesize needs to be computed at run time because
> the valgrind executables in a LDP release need to be able to handle both 4K and
> 64K pagesizes.
>
> I changed VKI_PAGE_SHIFT to be a variable and initialized it in m_main.c/main()
> (by looking through the auxiliary table as you suggested) before the first use
> in the call to VG_(am_startup).
>
> include/vki-ppc{32,64}-linux.h:
> /* PAGE_SHIFT determines the page size. On RHEL5 allows 64K page size */
> long __vki_page_shift;
>
> #define VKI_PAGE_SHIFT __vki_page_shift
> #define VKI_PAGE_SIZE (1UL << VKI_PAGE_SHIFT)
>
>
> This works for a little bit but then dies with:
> [...]
>
> I tracked this down to the #defines in coregrind/pub_core_aspacemgr.h:
> #define VG_STACK_GUARD_SZB 8192 // 2 pages
> #define VG_STACK_ACTIVE_SZB 65536 // 16 pages
>
> typedef
> struct {
> HChar bytes[VG_STACK_GUARD_SZB
> + VG_STACK_ACTIVE_SZB
> + VG_STACK_GUARD_SZB];
> }
> VgStack;
>
> I wonder if there are other places in the code that assume pagesize=4K?
Probably... this is a good way to flush them out :)
> I can't just change the #defines to be 2*VKI_PAGE_SIZE/16*VKI_PAGE_SIZE
> because they are now dynamic.
The good news is that it looks like it doesn't matter, because all the
stacks are actually VgStack* rather than VgStack -- ie. pointers to VgStack.
And the stacks are allocated in coregrind/m_aspacemgr/aspacemgr.c with
VG_(am_alloc_VgStack):
/* Allocate the stack. */
szB = VG_STACK_GUARD_SZB
+ VG_STACK_ACTIVE_SZB + VG_STACK_GUARD_SZB;
sres = VG_(am_mmap_anon_float_valgrind)( szB );
I think you can probably change the VgStack type to an array of zero bytes,
put a comment explaining things, and change VG_(am_alloc_VgStack) to use the
dynamically-determined page-size.
For 64KB pages, you should probably have one guard page at each end and one
stack page in the middle. (Julian might have more to add.)
Nick
|
|
From: Dave N. <dc...@us...> - 2006-10-13 21:48:31
|
What about VG_(interim_stack) in m_main.c? If I am understanding this code
correctly it appears that the asm routine for _start is using the statically
allocated VG_(interim_stack) and using it for the stack instead of the one the
kernel allocated.
Will this all work if I allocate VG_(interim_stack) off of the heap and change
the asm code for _start to refer to the allocated object?
Nicholas Nethercote wrote:
> On Thu, 12 Oct 2006, Dave Nomura wrote:
>
>> I went looking for that e-mail that you sent me that suggested that I look in
>> the auxiliary table for AT_PAGESIZE, and I found this earlier posting. This
>> posting addresses the problem that I'm trying to solve.
>>
>> Steve Munroe pointed out that pagesize needs to be computed at run time because
>> the valgrind executables in a LDP release need to be able to handle both 4K and
>> 64K pagesizes.
>>
>> I changed VKI_PAGE_SHIFT to be a variable and initialized it in m_main.c/main()
>> (by looking through the auxiliary table as you suggested) before the first use
>> in the call to VG_(am_startup).
>>
>> include/vki-ppc{32,64}-linux.h:
>> /* PAGE_SHIFT determines the page size. On RHEL5 allows 64K page size */
>> long __vki_page_shift;
>>
>> #define VKI_PAGE_SHIFT __vki_page_shift
>> #define VKI_PAGE_SIZE (1UL << VKI_PAGE_SHIFT)
>>
>>
>> This works for a little bit but then dies with:
>> [...]
>>
>> I tracked this down to the #defines in coregrind/pub_core_aspacemgr.h:
>> #define VG_STACK_GUARD_SZB 8192 // 2 pages
>> #define VG_STACK_ACTIVE_SZB 65536 // 16 pages
>>
>> typedef
>> struct {
>> HChar bytes[VG_STACK_GUARD_SZB
>> + VG_STACK_ACTIVE_SZB
>> + VG_STACK_GUARD_SZB];
>> }
>> VgStack;
>>
>> I wonder if there are other places in the code that assume pagesize=4K?
>
> Probably... this is a good way to flush them out :)
>
>> I can't just change the #defines to be 2*VKI_PAGE_SIZE/16*VKI_PAGE_SIZE
>> because they are now dynamic.
>
> The good news is that it looks like it doesn't matter, because all the
> stacks are actually VgStack* rather than VgStack -- ie. pointers to VgStack.
> And the stacks are allocated in coregrind/m_aspacemgr/aspacemgr.c with
> VG_(am_alloc_VgStack):
>
> /* Allocate the stack. */
> szB = VG_STACK_GUARD_SZB
> + VG_STACK_ACTIVE_SZB + VG_STACK_GUARD_SZB;
>
> sres = VG_(am_mmap_anon_float_valgrind)( szB );
>
> I think you can probably change the VgStack type to an array of zero bytes,
> put a comment explaining things, and change VG_(am_alloc_VgStack) to use the
> dynamically-determined page-size.
>
> For 64KB pages, you should probably have one guard page at each end and one
> stack page in the middle. (Julian might have more to add.)
>
> Nick
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Nicholas N. <nj...@cs...> - 2006-10-13 22:08:26
|
On Fri, 13 Oct 2006, Dave Nomura wrote: > What about VG_(interim_stack) in m_main.c? Ah, I didn't see that one. > If I am understanding this code correctly it appears that the asm routine > for _start is using the statically allocated VG_(interim_stack) and using > it for the stack instead of the one the kernel allocated. > > Will this all work if I allocate VG_(interim_stack) off of the heap and > change the asm code for _start to refer to the allocated object? I don't think you'll be able to do that, because it happens so early in main() that the dynamic memory manager hasn't yet started. I wonder if the exact size of this stack is so important. Perhaps you could not use the VgStack type, just use a fixed stack size (such as 64KB) that is independent of the page size? Judging from the comments, that might remove the stack overflow detection during startup, which may or may not be bad. It's an idea, but I really don't know much about this part of the system. Nick |
|
From: Dave N. <dc...@us...> - 2006-10-14 18:32:05
|
So, you are suggesting for the VG_(interim_stack) that I use 1 64K stack guard on both sides of the active stack (also 64K) and statically allocate it and use the same VG_(interim_stack) for both 64K and 4K pagesizes on PPC? My reading of VG_(interim_stack) suggests that it's size/alignment should match the real stack that is going to be allocated by VG_(am_alloc_VgStack) because V uses VG_(interim_stack) to figure out the legal address values for the stack. Julian? Nicholas Nethercote wrote: > On Fri, 13 Oct 2006, Dave Nomura wrote: > >> What about VG_(interim_stack) in m_main.c? > > Ah, I didn't see that one. > >> If I am understanding this code correctly it appears that the asm routine >> for _start is using the statically allocated VG_(interim_stack) and using >> it for the stack instead of the one the kernel allocated. >> >> Will this all work if I allocate VG_(interim_stack) off of the heap and >> change the asm code for _start to refer to the allocated object? > > I don't think you'll be able to do that, because it happens so early in > main() that the dynamic memory manager hasn't yet started. > > I wonder if the exact size of this stack is so important. Perhaps you could > not use the VgStack type, just use a fixed stack size (such as 64KB) that is > independent of the page size? Judging from the comments, that might remove > the stack overflow detection during startup, which may or may not be bad. > > It's an idea, but I really don't know much about this part of the system. > > Nick > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Julian S. <js...@ac...> - 2006-10-14 19:20:22
|
It would be helpful to have a big picture of what you (collectively)
are trying to achieve. You are trying to construct user-space
for ppc-linux so that everything transparently works whether the
kernel is doing 4k or 64k pages, is that correct?
Anyway:
I suggest you change the definition of VgStack so it always consists
of 3 64k segments. (iow, change VG_STACK_GUARD_SZB to 65536). Then:
- you can ignore VG_(interim_stack); that should just work ok. There
is no protection for the guard pages of VG_(interim_stack); all that
ever happens is that the address of the top of the active area is
loaded into sp at startup time. See the assembly at the bottom
of m_main.c.
- VG_(am_alloc_VgStack) should still be able to protect the guard
page(s) of the stack it allocates.
That fixes that problem. Unfortunately it wastes space on all 4k
page platforms, but you can't dynamically allocate VG_(interim_stack)
for the reasons Nick explained.
The idea of changing VKI_PAGE_SIZE into a variable is going to cause
a problem in coregrind/m_replacemalloc/vg_replace_malloc.c in the
wrapper for valloc. This file is compiled into one of the _preload.so
files and so you will get a link error (at run time). I suggest you
do as the man page for valloc suggests, replace the reference to
VKI_PAGE_SIZE to a call 'sysconf(_SC_PAGESIZE)'.
J
On Friday 13 October 2006 22:51, Dave Nomura wrote:
> What about VG_(interim_stack) in m_main.c? If I am understanding this code
> correctly it appears that the asm routine for _start is using the
> statically allocated VG_(interim_stack) and using it for the stack instead
> of the one the kernel allocated.
>
> Will this all work if I allocate VG_(interim_stack) off of the heap and
> change the asm code for _start to refer to the allocated object?
>
> Nicholas Nethercote wrote:
> > On Thu, 12 Oct 2006, Dave Nomura wrote:
> >> I went looking for that e-mail that you sent me that suggested that I
> >> look in the auxiliary table for AT_PAGESIZE, and I found this earlier
> >> posting. This posting addresses the problem that I'm trying to solve.
> >>
> >> Steve Munroe pointed out that pagesize needs to be computed at run time
> >> because the valgrind executables in a LDP release need to be able to
> >> handle both 4K and 64K pagesizes.
> >>
> >> I changed VKI_PAGE_SHIFT to be a variable and initialized it in
> >> m_main.c/main() (by looking through the auxiliary table as you
> >> suggested) before the first use in the call to VG_(am_startup).
> >>
> >> include/vki-ppc{32,64}-linux.h:
> >> /* PAGE_SHIFT determines the page size. On RHEL5 allows 64K page size */
> >> long __vki_page_shift;
> >>
> >> #define VKI_PAGE_SHIFT __vki_page_shift
> >> #define VKI_PAGE_SIZE (1UL << VKI_PAGE_SHIFT)
> >>
> >>
> >> This works for a little bit but then dies with:
> >> [...]
> >>
> >> I tracked this down to the #defines in coregrind/pub_core_aspacemgr.h:
> >> #define VG_STACK_GUARD_SZB 8192 // 2 pages
> >> #define VG_STACK_ACTIVE_SZB 65536 // 16 pages
> >>
> >> typedef
> >> struct {
> >> HChar bytes[VG_STACK_GUARD_SZB
> >> + VG_STACK_ACTIVE_SZB
> >> + VG_STACK_GUARD_SZB];
> >> }
> >> VgStack;
> >>
> >> I wonder if there are other places in the code that assume pagesize=4K?
> >
> > Probably... this is a good way to flush them out :)
> >
> >> I can't just change the #defines to be 2*VKI_PAGE_SIZE/16*VKI_PAGE_SIZE
> >> because they are now dynamic.
> >
> > The good news is that it looks like it doesn't matter, because all the
> > stacks are actually VgStack* rather than VgStack -- ie. pointers to
> > VgStack. And the stacks are allocated in
> > coregrind/m_aspacemgr/aspacemgr.c with VG_(am_alloc_VgStack):
> >
> > /* Allocate the stack. */
> > szB = VG_STACK_GUARD_SZB
> > + VG_STACK_ACTIVE_SZB + VG_STACK_GUARD_SZB;
> >
> > sres = VG_(am_mmap_anon_float_valgrind)( szB );
> >
> > I think you can probably change the VgStack type to an array of zero
> > bytes, put a comment explaining things, and change VG_(am_alloc_VgStack)
> > to use the dynamically-determined page-size.
> >
> > For 64KB pages, you should probably have one guard page at each end and
> > one stack page in the middle. (Julian might have more to add.)
> >
> > Nick
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Valgrind-developers mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Julian S. <js...@ac...> - 2006-10-16 17:23:37
|
> Does the configuration of the VG_(interim_stack) have to match the one > created by VG_(am_alloc_VgStack)? No. The VG_(interim_stack) doesn't even have to have type VgStack; it was just the simple and obvious thing to do. At least it when we had page sizes known at compile time. It could just be a normal block of memory, eg UChar[65536]. Doing that would leave you free to have VG_(am_alloc_VgStack) allocate p/64k/p stacks where p is the current page size. That is simple and avoids wasting space on 4k-page machines. J |
|
From: Nicholas N. <nj...@cs...> - 2006-10-14 23:13:23
|
On Sat, 14 Oct 2006, Julian Seward wrote: > The idea of changing VKI_PAGE_SIZE into a variable is going to cause > a problem in coregrind/m_replacemalloc/vg_replace_malloc.c in the > wrapper for valloc. This file is compiled into one of the _preload.so > files and so you will get a link error (at run time). I suggest you > do as the man page for valloc suggests, replace the reference to > VKI_PAGE_SIZE to a call 'sysconf(_SC_PAGESIZE)'. Isn't that a libc function? In which case he won't be able to call it from Valgrind code? Nick |
|
From: Julian S. <js...@ac...> - 2006-10-14 23:22:19
|
On Sunday 15 October 2006 00:13, Nicholas Nethercote wrote: > On Sat, 14 Oct 2006, Julian Seward wrote: > > The idea of changing VKI_PAGE_SIZE into a variable is going to cause > > a problem in coregrind/m_replacemalloc/vg_replace_malloc.c in the > > wrapper for valloc. This file is compiled into one of the _preload.so > > files and so you will get a link error (at run time). I suggest you > > do as the man page for valloc suggests, replace the reference to > > VKI_PAGE_SIZE to a call 'sysconf(_SC_PAGESIZE)'. > > Isn't that a libc function? In which case he won't be able to call it from > Valgrind code? That would be true if this was 'in valgrind'; but vg_replace_malloc.c is part of one of the preloaded .so's which run on the guest CPU. If you see what I mean. J |
|
From: Dave N. <dc...@us...> - 2006-10-16 17:03:37
|
Yes, I am just trying to get valgrind to work on RHEL5 PPC where
pagesize could be either 4K or 64K depending on which ppc processor is
being used.
Julian Seward wrote:
> It would be helpful to have a big picture of what you (collectively)
> are trying to achieve. You are trying to construct user-space
> for ppc-linux so that everything transparently works whether the
> kernel is doing 4k or 64k pages, is that correct?
>
> Anyway:
>
> I suggest you change the definition of VgStack so it always consists
> of 3 64k segments. (iow, change VG_STACK_GUARD_SZB to 65536). Then:
>
> - you can ignore VG_(interim_stack); that should just work ok. There
> is no protection for the guard pages of VG_(interim_stack); all that
> ever happens is that the address of the top of the active area is
> loaded into sp at startup time. See the assembly at the bottom
> of m_main.c.
>
> - VG_(am_alloc_VgStack) should still be able to protect the guard
> page(s) of the stack it allocates.
>
> That fixes that problem. Unfortunately it wastes space on all 4k
> page platforms, but you can't dynamically allocate VG_(interim_stack)
> for the reasons Nick explained.
>
Does the configuration of the VG_(interim_stack) have to match the one
created by VG_(am_alloc_VgStack)?
Is there a problem is VG_(interim_stack) is 64K/64K/64K but
VG_(am_alloc_VgStack) allocates a 4K/64K/4K stack on machines with
pagesize=4K?
> The idea of changing VKI_PAGE_SIZE into a variable is going to cause
> a problem in coregrind/m_replacemalloc/vg_replace_malloc.c in the
> wrapper for valloc. This file is compiled into one of the _preload.so
> files and so you will get a link error (at run time). I suggest you
> do as the man page for valloc suggests, replace the reference to
> VKI_PAGE_SIZE to a call 'sysconf(_SC_PAGESIZE)'.
>
> J
>
>
>
> On Friday 13 October 2006 22:51, Dave Nomura wrote:
>
>> What about VG_(interim_stack) in m_main.c? If I am understanding this code
>> correctly it appears that the asm routine for _start is using the
>> statically allocated VG_(interim_stack) and using it for the stack instead
>> of the one the kernel allocated.
>>
>> Will this all work if I allocate VG_(interim_stack) off of the heap and
>> change the asm code for _start to refer to the allocated object?
>>
>> Nicholas Nethercote wrote:
>>
>>> On Thu, 12 Oct 2006, Dave Nomura wrote:
>>>
>>>> I went looking for that e-mail that you sent me that suggested that I
>>>> look in the auxiliary table for AT_PAGESIZE, and I found this earlier
>>>> posting. This posting addresses the problem that I'm trying to solve.
>>>>
>>>> Steve Munroe pointed out that pagesize needs to be computed at run time
>>>> because the valgrind executables in a LDP release need to be able to
>>>> handle both 4K and 64K pagesizes.
>>>>
>>>> I changed VKI_PAGE_SHIFT to be a variable and initialized it in
>>>> m_main.c/main() (by looking through the auxiliary table as you
>>>> suggested) before the first use in the call to VG_(am_startup).
>>>>
>>>> include/vki-ppc{32,64}-linux.h:
>>>> /* PAGE_SHIFT determines the page size. On RHEL5 allows 64K page size */
>>>> long __vki_page_shift;
>>>>
>>>> #define VKI_PAGE_SHIFT __vki_page_shift
>>>> #define VKI_PAGE_SIZE (1UL << VKI_PAGE_SHIFT)
>>>>
>>>>
>>>> This works for a little bit but then dies with:
>>>> [...]
>>>>
>>>> I tracked this down to the #defines in coregrind/pub_core_aspacemgr.h:
>>>> #define VG_STACK_GUARD_SZB 8192 // 2 pages
>>>> #define VG_STACK_ACTIVE_SZB 65536 // 16 pages
>>>>
>>>> typedef
>>>> struct {
>>>> HChar bytes[VG_STACK_GUARD_SZB
>>>> + VG_STACK_ACTIVE_SZB
>>>> + VG_STACK_GUARD_SZB];
>>>> }
>>>> VgStack;
>>>>
>>>> I wonder if there are other places in the code that assume pagesize=4K?
>>>>
>>> Probably... this is a good way to flush them out :)
>>>
>>>
>>>> I can't just change the #defines to be 2*VKI_PAGE_SIZE/16*VKI_PAGE_SIZE
>>>> because they are now dynamic.
>>>>
>>> The good news is that it looks like it doesn't matter, because all the
>>> stacks are actually VgStack* rather than VgStack -- ie. pointers to
>>> VgStack. And the stacks are allocated in
>>> coregrind/m_aspacemgr/aspacemgr.c with VG_(am_alloc_VgStack):
>>>
>>> /* Allocate the stack. */
>>> szB = VG_STACK_GUARD_SZB
>>> + VG_STACK_ACTIVE_SZB + VG_STACK_GUARD_SZB;
>>>
>>> sres = VG_(am_mmap_anon_float_valgrind)( szB );
>>>
>>> I think you can probably change the VgStack type to an array of zero
>>> bytes, put a comment explaining things, and change VG_(am_alloc_VgStack)
>>> to use the dynamically-determined page-size.
>>>
>>> For 64KB pages, you should probably have one guard page at each end and
>>> one stack page in the middle. (Julian might have more to add.)
>>>
>>> Nick
>>>
>>> -------------------------------------------------------------------------
>>> Using Tomcat but need to do more? Need to support web services, security?
>>> Get stuff done quickly with pre-integrated technology to make your job
>>> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
>>> Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> Valgrind-developers mailing list
>>> Val...@li...
>>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job
>> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Valgrind-developers mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>
|
|
From: Dave N. <dc...@us...> - 2006-10-19 04:22:38
|
I found some more places that uses VKI_PAGE_SIZE in m_ume.c. The two references in mapelf() and load_ELF() look like they are using VKI_PAGE_SIZE as "the pagesize", but the two references in load_script() and VG_(pre_exec_check) are, I believe, using VKI_PAGE_SIZE is just a sufficiently large chunk of buffer size to read in enough of the script, or elf executable file to file to be able to call match_ELF(), match_script() or to parse some of the stuff in the interpreter script. Since my change makes VKI_PAGE_SIZE a variable, I replaced these two references in load_script() and VG_(pre_exec_check) by VKI_STATIC_PAGE_SIZE which was the larger of the two possible choices. This caused problems because it was pushing onto the stack an array of 64K bytes and was overflowing the stack. In VG_(pre_exec_check) the call to VG_(pread) was writing onto some of my global variables and the program crashed. The change I am proposing is to replace these two references to VKI_PAGE_SIZE in load_script() and VG_(pre_exec_check) by INITIAL_CHUNK_SIZE which I've defined locally as 4K. How does this sound to you? I can now run the regression test suite although I get a lot of diffs like: exitprog.stderr.diff + WARNING: Thread 1 is within 50576 bytes of running out of stack! Can you think of a reason why the stack usage would be different on a machine with a different pagesize? Are there some pagesize chunks of memory allocated that would reduce the amount of space available for the stack? Maybe there is some other area that requires some pagesize dependent changes? pointer-trace.stderr.diff *** 20 **** ! 1,048,576 bytes in 1 blocks are definitely lost in loss record 1 of 1 --- 20 ---- ! 1,048,576 bytes in 1 blocks are possibly lost in loss record 1 of 1 No idea what might cause this difference. pointer-trace.stderr.diff64 *** 20 **** ! 2,097,152 bytes in 1 blocks are definitely lost in loss record 1 of 1 --- 20 ---- ! 1,048,576 bytes in 1 blocks are possibly lost in loss record 1 of 1 Does this look at all familiar? Any guesses why twice as many blocks would be lost? definittely vs. possibly? Julian Seward wrote: >> Does the configuration of the VG_(interim_stack) have to match the one >> created by VG_(am_alloc_VgStack)? >> > > No. The VG_(interim_stack) doesn't even have to have type VgStack; > it was just the simple and obvious thing to do. At least it when we > had page sizes known at compile time. It could just be a normal > block of memory, eg UChar[65536]. Doing that would leave you free > to have VG_(am_alloc_VgStack) allocate p/64k/p stacks where p is > the current page size. That is simple and avoids wasting space on > 4k-page machines. > > J > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Nicholas N. <nj...@cs...> - 2006-10-19 05:34:48
|
On Wed, 18 Oct 2006, Dave Nomura wrote: > I found some more places that uses VKI_PAGE_SIZE in m_ume.c. The two > references in mapelf() and load_ELF() look like they are using VKI_PAGE_SIZE > as "the pagesize", but the two references in load_script() and > VG_(pre_exec_check) are, I believe, using VKI_PAGE_SIZE is just a > sufficiently large chunk of buffer size to read in enough of the script, or > elf executable file to file to be able to call match_ELF(), match_script() or > to parse some of the stuff in the interpreter script. Since my change makes > VKI_PAGE_SIZE a variable, I replaced these two references in load_script() > and VG_(pre_exec_check) by VKI_STATIC_PAGE_SIZE which was the larger of the > two possible choices. This caused problems because it was pushing onto the > stack an array of 64K bytes and was overflowing the stack. In > VG_(pre_exec_check) the call to VG_(pread) was writing onto some of my global > variables and the program crashed. > > The change I am proposing is to replace these two references to VKI_PAGE_SIZE > in load_script() and VG_(pre_exec_check) by INITIAL_CHUNK_SIZE which I've > defined locally as 4K. Nice detective work! INITIAL_CHUNK_SIZE == 4k sounds reasonable to me. > How does this sound to you? I can now run the regression test suite although > I get a lot of diffs like: > exitprog.stderr.diff > + WARNING: Thread 1 is within 50576 bytes of running out of stack! > Can you think of a reason why the stack usage would be different on a machine > with a different pagesize? Are there some pagesize chunks of memory allocated > that would reduce the amount of space available for the stack? > Maybe there is some other area that requires some pagesize dependent changes? I don't know about that. Maybe that check detects if you are within VKI_PAGE_SIZE of running out of stack? Which with 64KB pages isn't a big deal, but with 4KB pages it's more dangerous. If so, changing the constant again to 4KB (with a different name) seems reasonable. > pointer-trace.stderr.diff > *** 20 **** > ! 1,048,576 bytes in 1 blocks are definitely lost in loss record 1 of 1 > --- 20 ---- > ! 1,048,576 bytes in 1 blocks are possibly lost in loss record 1 of 1 > No idea what might cause this difference. I'm pretty sure that's harmless, just random noise. > pointer-trace.stderr.diff64 > *** 20 **** > ! 2,097,152 bytes in 1 blocks are definitely lost in loss record 1 of 1 > --- 20 ---- > ! 1,048,576 bytes in 1 blocks are possibly lost in loss record 1 of 1 > Does this look at all familiar? Any guesses why twice as many blocks would > be lost? definittely vs. possibly? I don't know about that one, but pointer-trace fails all the time in the nightly regression tests. The .exp64 output might just be wrong? Nick |
|
From: Julian S. <js...@ac...> - 2006-10-19 18:13:11
|
> > How does this sound to you? I can now run the regression test suite > > although I get a lot of diffs like: > > exitprog.stderr.diff > > + WARNING: Thread 1 is within 50576 bytes of running out of stack! > I don't know about that. Maybe that check detects if you are within > VKI_PAGE_SIZE of running out of stack? Which with 64KB pages isn't a big > deal, but with 4KB pages it's more dangerous. If so, changing the constant > again to 4KB (with a different name) seems reasonable. I agree with this analysis. > > pointer-trace.stderr.diff > > *** 20 **** > > ! 1,048,576 bytes in 1 blocks are definitely lost in loss record 1 of 1 > > --- 20 ---- > > ! 1,048,576 bytes in 1 blocks are possibly lost in loss record 1 of 1 > > No idea what might cause this difference. > > I'm pretty sure that's harmless, just random noise. Hard to fix. Ignore. Remember, you're not trying to get zero regtest failures; you're trying to ensure you get the same regtest failures when all the regtests run in 64k-page mode as they do in 4k-page mode. > > ! 2,097,152 bytes in 1 blocks are definitely lost in loss record 1 of 1 > > --- 20 ---- > > ! 1,048,576 bytes in 1 blocks are possibly lost in loss record 1 of 1 > > Does this look at all familiar? Any guesses why twice as many blocks > > would be lost? definittely vs. possibly? The .stderr.exp64 is the expected output for 64-bit platforms. This program I suspect allocates an array of 262144 pointers and so it's not surprising the leaked quantity is exactly half the required amount if you are running in 32-bit mode. Ignore. ---------- I presume you'll be sending a patch for review at some point? ---------- You should think about how to ensure the new functionality doesn't get broken in the future -- bearing in mind none (AFAIK) of the available test machines are ppc systems with 64k pages. We know from experience that functionality which is not automatically tested tends to get broken over time. One effective solution is to run the nightly build system on your own 64k-page development box. Another is to add regression tests; although I'm not sure how/what they would look like. J |
|
From: Nicholas N. <nj...@cs...> - 2006-10-26 01:27:55
|
This bug report was added to the database: http://bugs.kde.org/show_bug.cgi?id=136300 It seems to be addressing the same issue, and there's a patch. I haven't looked at it so I don't know how it compares to your code, but it might be worthwhile looking at it. Nick On Wed, 25 Oct 2006, Dave Nomura wrote: > Julian Seward wrote: >> ---------- >> >> I presume you'll be sending a patch for review at some point? >> > yes, working on it. > > a couple of other issues: > 1. I am dealing with glibc version 2.5 so have already encountered 1 > change needed in the default.supp file. > Do you have any recommendation about how to go about creating a new > glibc-2.5.supp? > start with glibc-2.4 and add stuff as needed? start with an empty file? > > 2. I am making changes to include/vki-ppc{32,64}-linux.h to make > VKI_PAGE_SHIFT and VKI_PAGE_SIZE dependent on initializiation of a > variable. I notice that these files are installed and made available > for public consumption. I initialize the variable that these #defines > depend on in valgrind, but a user that unwittingly uses them in a test > program would be referencing an uninitialized variable. > > How do you think we should handle this? > 1. Change valgrind to use different macros than the VKI_PAGE_* macros? > 2. put some #ifdef's around the ppc VKI_PAGE_* macros, with maybe the 4K > page size as the default, allow the 64K pagesize to be selected by > -DWANT_64K_PAGESIZE, or use the dynamic sizes required by Valgrind > controlled by something like -DWANT_DYNAMIC_PAGESIZE > 3. ??? > >> ---------- >> >> You should think about how to ensure the new functionality doesn't get >> broken in the future -- bearing in mind none (AFAIK) of the available >> test machines are ppc systems with 64k pages. We know from experience >> that functionality which is not automatically tested tends to get >> broken over time. >> >> One effective solution is to run the nightly build system on your own >> 64k-page development box. Another is to add regression tests; although >> I'm not sure how/what they would look like. >> > I'm not sure how I would make specific regression tests either but will > plan on running the regression tests from time to time. > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Dave N. <dc...@us...> - 2006-10-26 17:05:39
|
His patch is very similar to mine but includes some fixes for things
that I hadn't figure out so I prefer his over mine. Also, he addressed
the issue of modifying vki-ppc{32,64}-linux.h by allowing for both 4K
and 64K without introducing the run-time variable. Instead, he just
defined local variables in m_main.c called VKI_PAGE_SIZE/VKI_PAGE_SHIFT
and initialized them from the ELF Auxillary table.
Please let me know if you are planning on pushing this upstream soon. I
am planning on pointing RedHat at this patch for their upcoming RHEL5
release.
The only thing that is needed to make the regression suite run cleaner
on glibc-2.5 is a new glibc-2.5.supp which is just a copy of glibc-2.4
with the following addition:
{
glibc-2.5-hack-1
Memcheck:Cond
obj:/lib*/ld-2.5.so
obj:/lib*/ld-2.5.so
obj:/lib*/ld-2.5.so
obj:/lib*/ld-2.5.so
obj:/lib*/ld-2.5.so
obj:/lib*/ld-2.5.so
}
Nicholas Nethercote wrote:
> This bug report was added to the database:
>
> http://bugs.kde.org/show_bug.cgi?id=136300
>
> It seems to be addressing the same issue, and there's a patch. I haven't
> looked at it so I don't know how it compares to your code, but it might be
> worthwhile looking at it.
>
> Nick
>
>
> On Wed, 25 Oct 2006, Dave Nomura wrote:
>
>
>> Julian Seward wrote:
>>
>>> ----------
>>>
>>> I presume you'll be sending a patch for review at some point?
>>>
>>>
>> yes, working on it.
>>
>> a couple of other issues:
>> 1. I am dealing with glibc version 2.5 so have already encountered 1
>> change needed in the default.supp file.
>> Do you have any recommendation about how to go about creating a new
>> glibc-2.5.supp?
>> start with glibc-2.4 and add stuff as needed? start with an empty file?
>>
>> 2. I am making changes to include/vki-ppc{32,64}-linux.h to make
>> VKI_PAGE_SHIFT and VKI_PAGE_SIZE dependent on initializiation of a
>> variable. I notice that these files are installed and made available
>> for public consumption. I initialize the variable that these #defines
>> depend on in valgrind, but a user that unwittingly uses them in a test
>> program would be referencing an uninitialized variable.
>>
>> How do you think we should handle this?
>> 1. Change valgrind to use different macros than the VKI_PAGE_* macros?
>> 2. put some #ifdef's around the ppc VKI_PAGE_* macros, with maybe the 4K
>> page size as the default, allow the 64K pagesize to be selected by
>> -DWANT_64K_PAGESIZE, or use the dynamic sizes required by Valgrind
>> controlled by something like -DWANT_DYNAMIC_PAGESIZE
>> 3. ???
>>
>>
>>> ----------
>>>
>>> You should think about how to ensure the new functionality doesn't get
>>> broken in the future -- bearing in mind none (AFAIK) of the available
>>> test machines are ppc systems with 64k pages. We know from experience
>>> that functionality which is not automatically tested tends to get
>>> broken over time.
>>>
>>> One effective solution is to run the nightly build system on your own
>>> 64k-page development box. Another is to add regression tests; although
>>> I'm not sure how/what they would look like.
>>>
>>>
>> I'm not sure how I would make specific regression tests either but will
>> plan on running the regression tests from time to time.
>>
>>
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Valgrind-developers mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>
>>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|
|
From: Dave N. <dc...@us...> - 2006-10-26 00:15:13
|
Julian Seward wrote:
> ----------
>
> I presume you'll be sending a patch for review at some point?
>
yes, working on it.
a couple of other issues:
1. I am dealing with glibc version 2.5 so have already encountered 1
change needed in the default.supp file.
Do you have any recommendation about how to go about creating a new
glibc-2.5.supp?
start with glibc-2.4 and add stuff as needed? start with an empty file?
2. I am making changes to include/vki-ppc{32,64}-linux.h to make
VKI_PAGE_SHIFT and VKI_PAGE_SIZE dependent on initializiation of a
variable. I notice that these files are installed and made available
for public consumption. I initialize the variable that these #defines
depend on in valgrind, but a user that unwittingly uses them in a test
program would be referencing an uninitialized variable.
How do you think we should handle this?
1. Change valgrind to use different macros than the VKI_PAGE_* macros?
2. put some #ifdef's around the ppc VKI_PAGE_* macros, with maybe the 4K
page size as the default, allow the 64K pagesize to be selected by
-DWANT_64K_PAGESIZE, or use the dynamic sizes required by Valgrind
controlled by something like -DWANT_DYNAMIC_PAGESIZE
3. ???
> ----------
>
> You should think about how to ensure the new functionality doesn't get
> broken in the future -- bearing in mind none (AFAIK) of the available
> test machines are ppc systems with 64k pages. We know from experience
> that functionality which is not automatically tested tends to get
> broken over time.
>
> One effective solution is to run the nightly build system on your own
> 64k-page development box. Another is to add regression tests; although
> I'm not sure how/what they would look like.
>
I'm not sure how I would make specific regression tests either but will
plan on running the regression tests from time to time.
|
|
From: Dave N. <dc...@us...> - 2006-10-26 19:46:41
|
His patch is very similar to mine but includes some fixes for things
that I hadn't figure out so I prefer his over mine. Also, he addressed
the issue of modifying vki-ppc{32,64}-linux.h by allowing for both 4K
and 64K without introducing the run-time variable. Instead, he just
defined local variables in m_main.c called VKI_PAGE_SIZE/VKI_PAGE_SHIFT
and initialized them from the ELF Auxillary table.
I tested his patch out on our RHEL5 ppc w/ 64k pagesize and it works
just fine.
The only thing that is needed to make the regression suite run cleaner
on glibc-2.5 is a new glibc-2.5.supp which is just a copy of glibc-2.4
with the following addition:
{
glibc-2.5-hack-1
Memcheck:Cond
obj:/lib*/ld-2.5.so
obj:/lib*/ld-2.5.so
obj:/lib*/ld-2.5.so
obj:/lib*/ld-2.5.so
obj:/lib*/ld-2.5.so
obj:/lib*/ld-2.5.so
}
Please let me know if you are planning on pushing this upstream soon. I
am planning on pointing RedHat at this patch for their upcoming RHEL5
release.
Nicholas Nethercote wrote:
> This bug report was added to the database:
>
> http://bugs.kde.org/show_bug.cgi?id=136300
>
> It seems to be addressing the same issue, and there's a patch. I haven't
> looked at it so I don't know how it compares to your code, but it might be
> worthwhile looking at it.
>
> Nick
>
>
>
|
|
From: Julian S. <js...@ac...> - 2006-10-31 11:51:52
|
> Please let me know if you are planning on pushing this upstream soon. I > am planning on pointing RedHat at this patch for their upcoming RHEL5 > release. The patch attached to http://bugs.kde.org/show_bug.cgi?id=136300 is from Red Hat anyway so I assume they will ship it in their version of Valgrind for RHEL5. I'll look at committing it to the trunk, but I think you can assume it's not a big deal. Since nobody is running nightly builds on a 64k-page ppc system right now, we have no way to detect any future breakage to this functionality. So it's really up to you guys to ensure this stuff works and stays working. J |