Re: [DREAMCAST] : Buildfailure

Re: [DREAMCAST] : Buildfailure

[Kristoffer Ericson]

On Wed, 26 Dec 2007 15:55:16 +0900
Paul Mundt <lethal@linux-sh.org> wrote:

> On Thu, Dec 20, 2007 at 04:17:13PM +0900, Nobuhiro Iwamatsu wrote:
> > On Thu, 20 Dec 2007 02:44:54 +0100
> > Kristoffer Ericson <kristoffer.ericson@gmail.com> wrote:
> > > > It was possible to confirm it even in my environment. 
> > > > The problem occurs when it is gcc-3.4. 
> > > 
> > > Is this a bug in GCC or is it more of a design thing?
> > 
> > I do not understand in which there is a cause. 
> > If I have time, I want to examine it. 
> 
> There were a few inconsistencies, and also a const mismatch in the
> get_user() case. This fixes those up, and makes the get/put_user
> interfaces a bit more consistent, with more reliable type checking.
> 
> See if this fixes things for you, seems to do the trick with my gcc-3.x
> and gcc-4.x compilers.

Builds nicely now, thanks.

> 
> ---
> 
>  include/asm-sh/uaccess_32.h |   64 +++++++++++++++++++-------------------------
>  1 file changed, 28 insertions(+), 36 deletions(-)
> 
> diff --git a/include/asm-sh/uaccess_32.h b/include/asm-sh/uaccess_32.h
> index 59a9f20..50b2f0b 100644
> --- a/include/asm-sh/uaccess_32.h
> +++ b/include/asm-sh/uaccess_32.h
> @@ -95,11 +95,9 @@ static inline int __access_ok(unsigned long addr, unsigned long size)
>  }
>  #endif /* CONFIG_MMU */
>  
> -static inline int access_ok(int type, const void __user *p, unsigned long size)
> -{
> -	unsigned long addr = (unsigned long)p;
> -	return __access_ok(addr, size);
> -}
> +#define access_ok(type, addr, size)	\
> +	(__chk_user_ptr(addr),		\
> +	 __access_ok((unsigned long __force)(addr), (size)))
>  
>  /*
>   * Uh, these should become the main single-value transfer routines ...
> @@ -113,18 +111,16 @@ static inline int access_ok(int type, const void __user *p, unsigned long size)
>   * (a) re-use the arguments for side effects (sizeof is ok)
>   * (b) require any knowledge of processes at this stage
>   */
> -#define put_user(x,ptr)	__put_user_check((x),(ptr),sizeof(*(ptr)))
> -#define get_user(x,ptr) __get_user_check((x),(ptr),sizeof(*(ptr)))
> +#define put_user(x,ptr)		__put_user_check((x), (ptr), sizeof(*(ptr)))
> +#define get_user(x,ptr)		__get_user_check((x), (ptr), sizeof(*(ptr)))
>  
>  /*
>   * The "__xxx" versions do not do address space checking, useful when
>   * doing multiple accesses to the same area (the user has to do the
>   * checks by hand with "access_ok()")
>   */
> -#define __put_user(x,ptr) \
> -  __put_user_nocheck((__typeof__(*(ptr)))(x),(ptr),sizeof(*(ptr)))
> -#define __get_user(x,ptr) \
> -  __get_user_nocheck((x),(ptr),sizeof(*(ptr)))
> +#define __put_user(x,ptr)	__put_user_nocheck((x), (ptr), sizeof(*(ptr)))
> +#define __get_user(x,ptr)	__get_user_nocheck((x), (ptr), sizeof(*(ptr)))
>  
>  struct __large_struct { unsigned long buf[100]; };
>  #define __m(x) (*(struct __large_struct __user *)(x))
> @@ -132,7 +128,6 @@ struct __large_struct { unsigned long buf[100]; };
>  #define __get_user_size(x,ptr,size,retval)			\
>  do {								\
>  	retval = 0;						\
> -	__chk_user_ptr(ptr);					\
>  	switch (size) {						\
>  	case 1:							\
>  		__get_user_asm(x, ptr, retval, "b");		\
> @@ -151,24 +146,22 @@ do {								\
>  
>  #define __get_user_nocheck(x,ptr,size)				\
>  ({								\
> -	long __gu_err, __gu_val;				\
> -	__typeof__(*(ptr)) *__pu_addr = (ptr);  \
> -	__get_user_size(__gu_val, (__pu_addr), (size), __gu_err);	\
> +	long __gu_err;						\
> +	unsigned long __gu_val;					\
> +	const __typeof__(*(ptr)) __user *__gu_addr = (ptr);	\
> +	__chk_user_ptr(ptr);					\
> +	__get_user_size(__gu_val, __gu_addr, (size), __gu_err);	\
>  	(x) = (__typeof__(*(ptr)))__gu_val;			\
>  	__gu_err;						\
>  })
>  
>  #define __get_user_check(x,ptr,size)					\
>  ({									\
> -	long __gu_err, __gu_val;					\
> -	__typeof__(*(ptr)) *__pu_addr = (ptr);				\
> -	__chk_user_ptr(__pu_addr);					\
> -	if (likely(__addr_ok((unsigned long)(__pu_addr)))) {		\
> -		__get_user_size(__gu_val, (__pu_addr), (size), __gu_err);\
> -	} else {							\
> -		__gu_err = -EFAULT;					\
> -		__gu_val = 0;						\
> -	}								\
> +	long __gu_err = -EFAULT;					\
> +	unsigned long __gu_val = 0;					\
> +	const __typeof__(*(ptr)) *__gu_addr = (ptr);			\
> +	if (likely(access_ok(VERIFY_READ, __gu_addr, (size))))		\
> +		__get_user_size(__gu_val, __gu_addr, (size), __gu_err);	\
>  	(x) = (__typeof__(*(ptr)))__gu_val;				\
>  	__gu_err;							\
>  })
> @@ -199,7 +192,6 @@ extern void __get_user_unknown(void);
>  #define __put_user_size(x,ptr,size,retval)		\
>  do {							\
>  	retval = 0;					\
> -	__chk_user_ptr(ptr);				\
>  	switch (size) {					\
>  	case 1:						\
>  		__put_user_asm(x, ptr, retval, "b");	\
> @@ -218,22 +210,22 @@ do {							\
>  	}						\
>  } while (0)
>  
> -#define __put_user_nocheck(x,ptr,size)			\
> -({							\
> -	long __pu_err;					\
> -	__put_user_size((x),(ptr),(size),__pu_err);	\
> -	__pu_err;					\
> +#define __put_user_nocheck(x,ptr,size)				\
> +({								\
> +	long __pu_err;						\
> +	__typeof__(*(ptr)) __user *__pu_addr = (ptr);		\
> +	__chk_user_ptr(ptr);					\
> +	__put_user_size((x), __pu_addr, (size), __pu_err);	\
> +	__pu_err;						\
>  })
>  
>  #define __put_user_check(x,ptr,size)				\
>  ({								\
> -	long __pu_err;						\
> +	long __pu_err = -EFAULT;				\
>  	__typeof__(*(ptr)) __user *__pu_addr = (ptr);		\
> -								\
> -	if (likely(__addr_ok((unsigned long)__pu_addr)))	\
> -		__put_user_size((x),__pu_addr,(size),__pu_err);	\
> -	else							\
> -		__pu_err = -EFAULT;				\
> +	if (likely(access_ok(VERIFY_WRITE, __pu_addr, size)))	\
> +		__put_user_size((x), __pu_addr, (size),		\
> +				__pu_err);			\
>  	__pu_err;						\
>  })
>  


-- 
Kristoffer Ericson <Kristoffer.Ericson@Gmail.com>

Re: [DREAMCAST] : Buildfailure

[Paul Mundt]

Your mailer has completely mangled the To/From/Cc lines, in violation of
more than one RFC. Please seek out a more competent mailer for future
postings.

On Sat, Dec 29, 2007 at 04:32:40PM +0000, michiegan@eircom.net wrote:
> > > See if this fixes things for you, seems to do the trick with my gcc-3.x
> > > and gcc-4.x compilers.
> > 
> > Builds nicely now, thanks.
> > 
> Sorry to jump in on this thread but I'm trying to figure out what
> versions are needed for a dreamcast toolchain. ATM I've got this on
> working ( http://www.linuxdevices.com/articles/AT6973012857.html ) but
> it's rather old, including a 2.4.x kernel.
> 
> Recently I got a buildroot config that used gcc-3.4.1 but the current
> kernel. Does the dreamcast build with gcc-4.x at all? The few times
> I've tried it I've gotten missing pthreads.h errors that I haven't dug
> too deep into.
> 
> Further investgations into the likes of KOS seems to indicate that
> gcc-3.4.x is the latest version that will build dreamcast apps. I'm
> just trying to get a handle on what does and doesn't work. Considering
> the recent discussion from the kernel maintainers on dropping gcc-3.x
> all together in future kernels, I'd just like to know if/how to use
> gcc-4.x for dreamcast.
> 
There's nothing 'special' about the dreamcast. It's a legacy board under
the SH kernel, with no special casing. It doesn't require a special
toolchain or anything else, either. It's worked with gcc 4.x as long as
the SH kernel has supported gcc 4.x. Whatever KOS is smoking is
irrelevant.

There are multitudes of gcc 4.x toolchains available, both in binary and
source. See the Linux/SH wiki for more details: http://www.linux-sh.org.

If you find a build problem in buildroot, it's a bug, so you should log a
bugzilla entry for it. If people don't report bugs, it's difficult to
know what we need to look at.

Re: [DREAMCAST] : Buildfailure

[Paul Mundt]

On Mon, Dec 31, 2007 at 05:02:07PM +0000, michiegan@eircom.net wrote:
> Primarily I'm in this for the learning curve so I prefer doing
> everything by hand so I know what's going on, I know where everything
> is, and I'm hopelessly masochistic!
[snip]

> From your toolchain wiki page, it says that gcc-4.0.1 is as up-to-date
> as it gets. obviously the wiki page isn't up to date.
[more snippage]

Yes, it's quite possibly outdated in a lot of areas. Most of the stuff
documented is unrelated to specific version, so it's probably better to
just leave the versions ambiguous.

If you run in to issues with the wiki, either note them down and submit a
report to the list, or (preferred option) simply fix them up as you go
along. It's certainly our intent to have the wiki as useful as possible
for people, but obviously some content falls behind faster than others.

It would also be good to have an indicator of content that you feel is
missing from the wiki, or things that need to be expanded on to improve
clarity for those approaching these topics for the first time.