headers
Gregory McGarry | 1 Aug 2002 10:14
Picon

GDB and MMX

It seems that GDB won't dump the MMX registers on i386.  Is
this a known problem?  Using NetBSD 1.6.

	-- Gregory McGarry <g.mcgarry <at> ieee.org>
Permalink | Reply | 2 comments |
headers
Jason R Thorpe | 1 Aug 2002 19:42

Re: GDB and MMX

On Thu, Aug 01, 2002 at 08:14:35PM +1200, Gregory McGarry wrote:

 > It seems that GDB won't dump the MMX registers on i386.  Is
 > this a known problem?  Using NetBSD 1.6.

MMX registers == normal FP registers.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 1 comment |
headers
Gregory McGarry | 1 Aug 2002 22:50
Picon

Re: GDB and MMX

Jason R Thorpe wrote:

> On Thu, Aug 01, 2002 at 08:14:35PM +1200, Gregory McGarry wrote:
> 
>  > It seems that GDB won't dump the MMX registers on i386.  Is
>  > this a known problem?  Using NetBSD 1.6.
> 
> MMX registers == normal FP registers.

Sure.  But they're not the correct values.

	-- Gregory McGarry <g.mcgarry <at> ieee.org>
Permalink | Reply | 0 comments |
headers
Matt Thomas | 7 Aug 2002 10:20

Re: CVS commit: syssrc/sys/arch/powerpc/include

At 01:01 AM 8/7/2002, Tsubai Masanari wrote:

>Module Name:    syssrc
>Committed By:   tsubai
>Date:           Wed Aug  7 08:01:58 UTC 2002
>
>Modified Files:
>         syssrc/sys/arch/powerpc/include: ansi.h
>
>Log Message:
>Re-correct previous.  It's intentional.

It may be intention but it's wrong.  It's incompatible with the
GCC 3.* definition of va_list so that if you try to build GCC 3.*
for powerpc, it fails in libgcc building rtl.c.

This is because include/stdarg.h in gcc does a

typedef __builtin_va_list __gnuc_va_list;

followed by a

typedef __gnuc_va_list va_list;

Then libiberty.h defines

extern int vasprintf PARAMS ((char **, const char *, va_list));

where our stdio.h defines
(Continue reading)

Permalink | Reply | 18 comments |
headers
Matt Thomas | 7 Aug 2002 10:38

Re: CVS commit: syssrc/sys/arch/powerpc/include

At 01:20 AM 8/7/2002, Matt Thomas wrote:
>At 01:01 AM 8/7/2002, Tsubai Masanari wrote:
>
>>Module Name:    syssrc
>>Committed By:   tsubai
>>Date:           Wed Aug  7 08:01:58 UTC 2002
>>
>>Modified Files:
>>         syssrc/sys/arch/powerpc/include: ansi.h
>>
>>Log Message:
>>Re-correct previous.  It's intentional.
>
>It may be intention but it's wrong.  It's incompatible with the
>GCC 3.* definition of va_list so that if you try to build GCC 3.*
>for powerpc, it fails in libgcc building rtl.c.

Also, all of the ports that have GCC 3.* support, (eventually)
use a simple

typedef __builtin_va_list __va_list;

without wrapping it in a structure.  Why does powerpc need to wrap
a struct around it?

--

-- 
Matt Thomas               Internet:   matt <at> 3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tsubai Masanari | 7 Aug 2002 11:15
Picon

Re: CVS commit: syssrc/sys/arch/powerpc/include

>It may be intention but it's wrong.  It's incompatible with the
>GCC 3.* definition of va_list so that if you try to build GCC 3.*
>for powerpc, it fails in libgcc building rtl.c.

But your version is incompatible with our <= 2.95 version and other
NetBSD ports (and even it doesn't compile).  You should fix gcc instead.
I always use gcc 3.x to compile whole NetBSD tree on powerpc rather
than buggy 2.95.3.

diff -5Ncdr gcc-3.1.1/gcc/config/rs6000/t-netbsd gcc-3.1.1/gcc/config/rs6000/t-netbsd
*** gcc-3.1.1/gcc/config/rs6000/t-netbsd	Thu Jan  1 09:00:00 1970
--- gcc-3.1.1/gcc/config/rs6000/t-netbsd	Sat Jul 27 17:11:14 2002
***************
*** 0 ****
--- 1,2 ----
+ EXTRA_MULTILIB_PARTS=
+ USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS)
diff -5Ncdr gcc-3.1.1/gcc/config.gcc gcc-3.1.1/gcc/config.gcc
*** gcc-3.1.1/gcc/config.gcc	Sat Jun  8 08:35:31 2002
--- gcc-3.1.1/gcc/config.gcc	Sat Jul 27 17:01:47 2002
***************
*** 2803,2813 ****
  	xm_defines=POSIX
  	tmake_file="rs6000/t-ppcos rs6000/t-ppccomm"
  	;;
  powerpc-*-netbsd*)
  	tm_file="${tm_file} dbxelf.h elfos.h svr4.h freebsd-spec.h rs6000/sysv4.h rs6000/netbsd.h"
! 	tmake_file="rs6000/t-ppcos rs6000/t-ppccomm"
  	;;
  powerpc-*-chorusos*)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Thomas | 7 Aug 2002 11:30

Re: CVS commit: syssrc/sys/arch/powerpc/include

At 02:15 AM 8/7/2002, Tsubai Masanari wrote:
> >It may be intention but it's wrong.  It's incompatible with the
> >GCC 3.* definition of va_list so that if you try to build GCC 3.*
> >for powerpc, it fails in libgcc building rtl.c.
>
>But your version is incompatible with our <= 2.95 version and other
>NetBSD ports (and even it doesn't compile).  You should fix gcc instead.
>I always use gcc 3.x to compile whole NetBSD tree on powerpc rather
>than buggy 2.95.3.

Here's the diff that I applied:

*** ansi.h      2002/06/01 09:22:44     1.12
--- ansi.h      2002/08/07 00:10:29
***************
*** 60,73 ****
   #define       _BSD_SUSECONDS_T_       int             /* suseconds_t */
   #define       _BSD_USECONDS_T_        unsigned int    /* useconds_t */
   #define       _BSD_VA_LIST_           __va_list       /* va_list */
! typedef struct {
   #if __GNUC_PREREQ__(3, 0)
!       __builtin_va_list __va;
   #else
         char __gpr, __fpr, __pad[2];
         char *__stack, *__base;
- #endif
   } __va_list;

   /*
    * NOTE: rune_t is not covered by ANSI nor other standards, and should not
(Continue reading)

Permalink | Reply | 16 comments |
headers
Noriyuki Soda | 7 Aug 2002 14:00
Picon

Re: CVS commit: syssrc/sys/arch/powerpc/include

I've heard another concern from Tsubai privately. (*1)

In gcc-3.x, __builtin_va_list is array of struct (i.e. "struct{...}[1]"),
This means __builtin_va_list cannot be passed as a value in function
argument (because array cannot be passed as a value in C).

This means that all programs which assume that va_list can be passed
as a value in function argument will fail with gcc-3.x, if we use 
gcc __builtin_va_list as va_list.

Is this really OK? Why don't gcc people think this as a problem?

BTW, according to gcc-3.1.1 source, not only powerpc but also i386
has this problem about __builtin_va_list, if I read the source
correctly. ;-<
(mips seems to be OK, though).

(*1) www, people in Japan should try to write English more. ;)
  But writing English is so hard because there is huge difference
  between English language and Japanese language. ;-<
  SIGH.
--
soda
Permalink | Reply | 3 comments |
headers
David Laight | 7 Aug 2002 14:49
Picon

Re: CVS commit: syssrc/sys/arch/powerpc/include

> This means that all programs which assume that va_list can be passed
> as a value in function argument will fail with gcc-3.x, if we use 
> gcc __builtin_va_list as va_list.
> 
> Is this really OK? Why don't gcc people think this as a problem?

It can't be OK.
How do you call vprintf() if you can't pass a va_list to it by value?

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 2 comments |
headers
Noriyuki Soda | 7 Aug 2002 16:09
Picon

Re: CVS commit: syssrc/sys/arch/powerpc/include

>>>>> On Wed, 7 Aug 2002 13:49:40 +0100, David Laight <david <at> l8s.co.uk> said:

>> This means that all programs which assume that va_list can be passed
>> as a value in function argument will fail with gcc-3.x, if we use 
>> gcc __builtin_va_list as va_list.
>> 
>> Is this really OK? Why don't gcc people think this as a problem?

> It can't be OK.
> How do you call vprintf() if you can't pass a va_list to it by value?

Well, I relooked at C standard after I wrote the previous mail,
and found the following description:

	The type declared is
		va_list
	which is an object type suitable for holding information
	needed by the macros va_start, va_arg, va_end, and va_copy.
	If access to the varying arguments is desired, the called
	function shall declare an object (referred to as ap in this
	subclause) having type va_list. 
  ->	The object ap may be passed as an argument to another
  ->	function; if that function invokes the va_arg macro with
  ->	parameter ap, the value of ap in the calling function is
  ->	indeterminate and shall be passed to the va_end macro prior to
  ->	any further reference to ap.

This ("the value of ap in the calling function is indeterminate") may
be the reason that gcc choosed the implementation.
(This description exists in both C8X and C9X standard.)
(Continue reading)

Permalink | Reply | 1 comment |

Gmane