[Linux-ia64] new toolchain snapshots

[Linux-ia64] new toolchain snapshots

[Jim Wilson]

I am making available new toolchain snapshots, based on July FSF gcc sources.
These snapshots are available from ftp.cygnus.com in pub/ia64-linux.  The
current snapshot is in the snap-000828 directory.

The new toolchain is intended to support glibc 2.2.  Because of ABI changes,
the new toolchain will not work as is on any existing glibc 2.1.3 based
system.  There is a README.glibc213 file that will revert some of the ABI
changes allowing the toolchain to mostly work on existing systems.  This is
just a temporary workaround until glibc 2.2 based systems are available
though, and I don't expect to support this use of the toolchain.

The new toolchain is not as robust as the February-based toolchains yet.
There are a number of reported bugs against cpp that need to be investigated
and fixed.  There are some DV related problems that should be fixed.  Etc.
I won't consider this a production quality toolchain until someone has managed
to build a complete working linux system from it.  That hasn't happened yet.

If you want to build kernels from this toolchain, then you must use 2.4.0-test7
or later.  This toolchain will not build earlier kernels because of optimizer
changes that exposed problems with some of the extended asms in the kernel.

Jim

Re: [Linux-ia64] new toolchain snapshots

[Keith Owens]

On Wed, 30 Aug 2000 16:54:29 -0700, 
Jim Wilson <wilson@cygnus.com> wrote:
>I am making available new toolchain snapshots, based on July FSF gcc sources.
>These snapshots are available from ftp.cygnus.com in pub/ia64-linux.  The
>current snapshot is in the snap-000828 directory.

I'm getting a lot of warnings for format %p with the new toolchain on
kernel 2.4.0-test7, e.g.

pci-dma.c:100: warning: void format, char arg (arg 2)

static char *io_tlb_start, *io_tlb_end;
        printk("Placing software IO TLB between 0x%p - 0x%p\n", io_tlb_start, io_tlb_end);

What is the correct way to handle these?  Cast all pointers to (void *)
for printing or is there a compiler option I can use to make %p accept
any pointer, i.e. the old behaviour?

Re: [Linux-ia64] new toolchain snapshots

[Dan Pop]

On Thu, 31 Aug 2000, Keith Owens wrote:

> I'm getting a lot of warnings for format %p with the new toolchain on
> kernel 2.4.0-test7, e.g.
> 
> pci-dma.c:100: warning: void format, char arg (arg 2)
> 
> static char *io_tlb_start, *io_tlb_end;
>         printk("Placing software IO TLB between 0x%p - 0x%p\n", io_tlb_start, io_tlb_end);
> 
> What is the correct way to handle these?  Cast all pointers to (void *)
> for printing or is there a compiler option I can use to make %p accept
> any pointer, i.e. the old behaviour?

The *correct* way to fix it is to cast every argument corresponding to
a %p to void *, because this is what the C standard requires for printf.

Dan

Re: [Linux-ia64] new toolchain snapshots

[David Mosberger]

>>>>> On Thu, 31 Aug 2000 14:44:59 +0200 (MET DST), Dan Pop <Dan.Pop@cern.ch> said:

  Dan> On Thu, 31 Aug 2000, Keith Owens wrote:

  >> I'm getting a lot of warnings for format %p with the new
  >> toolchain on kernel 2.4.0-test7, e.g.
  >> 
  >> pci-dma.c:100: warning: void format, char arg (arg 2)
  >> 
  >> static char *io_tlb_start, *io_tlb_end; printk("Placing software
  >> IO TLB between 0x%p - 0x%p\n", io_tlb_start, io_tlb_end);
  >> 
  >> What is the correct way to handle these?  Cast all pointers to
  >> (void *) for printing or is there a compiler option I can use to
  >> make %p accept any pointer, i.e. the old behaviour?

  Dan> The *correct* way to fix it is to cast every argument
  Dan> corresponding to a %p to void *, because this is what the C
  Dan> standard requires for printf.

Geez, gotta love ANSI C...  I'll fix the ia64 specific kernel files.

	--david

Re: [Linux-ia64] new toolchain snapshots

[Jim Wilson]

	I'm getting a lot of warnings for format %p with the new toolchain on
	kernel 2.4.0-test7, e.g.

Before everyone goes and changes a lot of code, you should be aware that these
warnings have since changed several times in the FSF gcc sources.  And will
likely change again in the future.

The current FSF gcc sources won't give a warning for void * or char * used
with %p, and will accept other pointer types if you aren't using -pedantic.

We can either live with the current set of warnings, or I can try to bring over
patches from more recent FSF gcc sources to make them go away.

Jim

Re: [Linux-ia64] new toolchain snapshots

[David Mosberger]

>>>>> On Thu, 31 Aug 2000 13:08:07 -0700, Jim Wilson <wilson@cygnus.com> said:

  Jim> 	I'm getting a lot of warnings for format %p with the new
  Jim> toolchain on kernel 2.4.0-test7, e.g.

  Jim> Before everyone goes and changes a lot of code, you should be
  Jim> aware that these warnings have since changed several times in
  Jim> the FSF gcc sources.  And will likely change again in the
  Jim> future.

  Jim> The current FSF gcc sources won't give a warning for void * or
  Jim> char * used with %p, and will accept other pointer types if you
  Jim> aren't using -pedantic.

  Jim> We can either live with the current set of warnings, or I can
  Jim> try to bring over patches from more recent FSF gcc sources to
  Jim> make them go away.

OK, sounds good.

I should say that this issue bothers me much less than those stupid
"format is not a string constant" messages.  The reason I hate those
messages is because this is the only place gcc gives a warning without
there being a way to get rid of it.  I don't think this warning should
be turned on for -Wall.

	--david

PS: Yeah, I realize that I'm probably barking up the wrong tree.... ;-)

Re: [Linux-ia64] new toolchain snapshots

[Jim Wilson]

  Jim> We can either live with the current set of warnings, or I can
  Jim> try to bring over patches from more recent FSF gcc sources to
  Jim> make them go away.

>OK, sounds good.

What sounds good: living with it, or patching it away?

>PS: Yeah, I realize that I'm probably barking up the wrong tree.... ;-)

You are welcome to send a complaint to gcc-bugs@gcc.gnu.org.

Jim

Re: [Linux-ia64] new toolchain snapshots

[David Mosberger]

>>>>> On Thu, 31 Aug 2000 15:19:10 -0700, Jim Wilson <wilson@cygnus.com> said:

  Jim> We can either live with the current set of warnings, or I can
  Jim> try to bring over patches from more recent FSF gcc sources to
  Jim> make them go away.

  >> OK, sounds good.

  Jim> What sounds good: living with it, or patching it away?

Either way, actually.  I don't care much which way it goes, though in
the short term the old behavior (no warning when a pointer to a type
other than void is passed) is better, as it avoids massive amounts of
warnings.

  >> PS: Yeah, I realize that I'm probably barking up the wrong
  >> tree.... ;-)

  Jim> You are welcome to send a complaint to gcc-bugs@gcc.gnu.org.

Will do.

	--david

Re: [Linux-ia64] new toolchain snapshots

[Keith Owens]

On Wed, 30 Aug 2000 16:54:29 -0700, 
Jim Wilson <wilson@cygnus.com> wrote:
>I am making available new toolchain snapshots, based on July FSF gcc sources.
>These snapshots are available from ftp.cygnus.com in pub/ia64-linux.  The
>current snapshot is in the snap-000828 directory.

Compiling the 2.4.0-test7 code for fs/nfs/dir.c with this snapshot
generates an unresolved reference to __multi3, for no reason that I can
see.  The strange thing is that nm shows the unresolved reference but
objdump -r does not list it.  BTW, I applied the glibc 2.1.3 patch.

This patch stops the toolchain snapshot generating the reference to
__multi3.  Damned if I know why it works but it does.

Index: 0-test7.6/fs/nfs/dir.c
--- 0-test7.6/fs/nfs/dir.c Thu, 24 Aug 2000 03:29:10 +1000 kaos (linux-2.4/h/b/37_dir.c 1.1.1.4 644)
+++ 0-test7.6(w)/fs/nfs/dir.c Fri, 01 Sep 2000 15:43:21 +1100 kaos (linux-2.4/h/b/37_dir.c 1.1.1.4 644)
@@ -807,7 +807,7 @@ static int nfs_sillyrename(struct inode 
 	static unsigned int sillycounter = 0;
 	const int      i_inosize  = sizeof(dir_i->i_ino)*2;
 	const int      countersize = sizeof(sillycounter)*2;
-	const int      slen       = strlen(".nfs") + i_inosize + countersize;
+	const int      slen       = 4 + i_inosize + countersize;
 	char           silly[slen+1];
 	struct qstr    qsilly;
 	struct dentry *sdentry;

Re: [Linux-ia64] new toolchain snapshots

[Jim Wilson]

	Compiling the 2.4.0-test7 code for fs/nfs/dir.c with this snapshot
	generates an unresolved reference to __multi3, for no reason that I can
	see. 

There is no reference to __multi3.  Only a declaration for it.  The .s file has
      .globl __multi3
This causes it to be put in the symbol table where nm can see it, but does
not result in any relocation for it because we aren't using it.  This should
be harmless.

	const int      slen       = strlen(".nfs") + i_inosize + countersize;
 	char           silly[slen+1];

As for how we got there, the code is using a dynamic array/variable length
array.  If the size of the array is not a constant, then we must compute its
size at runtime so we can allocate it.  The size of the array is not a
constant because of the strlen call.  We can expand this as a built-in
function, but the result isn't a constant, it is a register (that holds a
constant).  Anyways, as far as the compiler is concerned it isn't a constant.
Internally, gcc computes object sizes as both bits and bytes.  This helps with
things like bitfields and bit-strings in Pascal like languages.  Since the
maximum size of an object is 2^64 bytes, a size in bits must be computed as
a 128 bit value to avoid losing precision.  We don't support 128 values
directly, so we have to call a libgcc library routine for the multiplication.
This routine is __multi3.  After generating code, the optimizer quickly figures
out that the object size is a constant after all, and the call to __multi3
is optimized away.  However, since we thought we needed the call when first
generating code, we emitted a declaration for it, because this is the default
for ELF targets.  This is because some assemblers give an error if you use
a function or variable before declaring it.  GNU as does not have this problem,
but the Intel as does.

This problem goes away if you replace the strlen call with a 4, because then
the object size is obviously a constant, and we don't need run-time code to
compute its size in bits.

If this really needs to be fixed for some reason, then we could override the
default definition of ASM_OUTPUT_EXTERNAL_LIBCALL.  We could define it to
only emit the __multi3 declaration if ias is being used.

Jim

Re: [Linux-ia64] new toolchain snapshots

[Keith Owens]

On Fri, 01 Sep 2000 20:01:21 -0700, 
Jim Wilson <wilson@cygnus.com> wrote:
>	Compiling the 2.4.0-test7 code for fs/nfs/dir.c with this snapshot
>	generates an unresolved reference to __multi3, for no reason that I can
>	see. 
>
>There is no reference to __multi3.  Only a declaration for it.  The .s file has
>      .globl __multi3
>This causes it to be put in the symbol table where nm can see it, but does
>not result in any relocation for it because we aren't using it.  This should
>be harmless.

It breaks modutils, depmod assumes that all unresolved externals in a
module are actually used.  I will complain to the modutils maintainer,
hang on, that's me :(.