Re: [parisc-linux] -pie is broken on hppa

["John David Anglin" <dave@hiauly1.hia.nrc.ca>]

> > The enclosed seems to fix both the libjava build and the svn problem.
> > Kyle's branch uses ALIGN instead of ROUND_UP.
> 
> This patch looks to be correct based on what's in
> fs/compat.c:compat_sys_getdents()/compat_filldir()

Let me just say that it's not obvious to me whether the patch is correct
or not.  It might be that we have always been short one byte.  On the
otherhand, we might be dealing with a userspace ABI change and we might
copy too much for programs linked using the "old" ABI.

What I saw was a d_reclen value of 24 for the file "Integer.class".
This value was one byte too small, so the null byte at the end of
the string "Integer.class" didn't get copied by scandir.  This caused
the filter function in jc1 to fail.

Userspace currently sees this struct:

struct dirent
  {
#ifndef __USE_FILE_OFFSET64
    __ino_t d_ino;
    __off_t d_off;
#else
    __ino64_t d_ino;
    __off64_t d_off;
#endif
    unsigned short int d_reclen;
    unsigned char d_type;
    char d_name[256];           /* We must not include limits.h! */
};

This is the struct used in filldir32 in sys_parisc32.c:

struct linux32_dirent {
        u32             d_ino;
	compat_off_t    d_off;
	u16             d_reclen;
	char            d_name[1];
};

The off by one error appears to be caused by the lack of the d_type field.
However, it's not clear to me why this doesn't result in the d_name field
being off by one.  Possibly, the d_type and d_name fields are treated as
one field by the caller of filldir32.  If that's the case, then the patch
is probably correct.  However, a comment as to why two is used instead of
one in the reclen calculation seems in order.

Guess __USE_FILE_OFFSET64 isn't supported.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)