headers
Martin Husemann | 17 Nov 2005 08:34
Picon

Gcc configure bug

Folks,

I think we have hit a generic gcc configure bug. Michael Lorenz discovered
that after my changes to default sparc64 to cpu=ultrasparc we can not build
NetBSD/sparc on a NetBSD/sparc64 host anymore.

The problem is this part of gcc's configure.in:

# Decode the host machine, then the target machine.
# For the host machine, we save the xm_file variable as host_xm_file;
# then we decode the target machine and forget everything else
# that came from the host machine.
for machine in $build $host $target; do
	. ${srcdir}/config.gcc
done

Now config.gcc sets various variables, but some of them not all the time.
My change (copied from the configurations for FreeBSD and OpenBSD) sets
with_cpu=ultrasparc.

When running above loop, we aquire $with_cpu=ultrasparc and then do the
last pass for the target, sparc--netbsdelf. The sparc case does use 
$with_cpu w/o any initialization in our src/tool build.

So guess what happens: we build a sparc compiler with -mcpu= defaulting
to ultrasparc. Since for the sparc build binutils is compiled as 32bit-only,
the resulting toolchain can not compile any program.

As a brute-force solution I would suggest this patch:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Martin Husemann | 17 Nov 2005 10:17
Picon

Re: Gcc configure bug

Ok, after some comments from Nick I looked at it again.

With the current state of config.gcc there is no good way to get what
we want with $target_cpu_default for sparc*. Since this is a lost battle
and we hopefully will get a newer compiler (that does this all different)
sometime soon, how about this patch? It should fix the problem and keep
command line semantics.

Martin

Index: configure.in
===================================================================
RCS file: /cvsroot/src/gnu/dist/gcc/gcc/configure.in,v
retrieving revision 1.4
diff -u -r1.4 configure.in
--- configure.in	10 Feb 2004 12:56:21 -0000	1.4
+++ configure.in	17 Nov 2005 09:13:45 -0000
 <at>  <at>  -880,8 +880,10  <at>  <at> 
 # For the host machine, we save the xm_file variable as host_xm_file;
 # then we decode the target machine and forget everything else
 # that came from the host machine.
+arg_with_cpu="$with_cpu"
 for machine in $build $host $target; do
 	. ${srcdir}/config.gcc
+	with_cpu="$arg_with_cpu"
 done

 extra_objs="${host_extra_objs} ${extra_objs}"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Earnshaw | 17 Nov 2005 14:45
Picon

Re: Gcc configure bug

On Thu, 2005-11-17 at 09:17, Martin Husemann wrote:
> Ok, after some comments from Nick I looked at it again.
> 
> With the current state of config.gcc there is no good way to get what
> we want with $target_cpu_default for sparc*. Since this is a lost battle
> and we hopefully will get a newer compiler (that does this all different)
> sometime soon, how about this patch? It should fix the problem and keep
> command line semantics.
> 
> Martin
> 
> Index: configure.in
> ===================================================================
> RCS file: /cvsroot/src/gnu/dist/gcc/gcc/configure.in,v
> retrieving revision 1.4
> diff -u -r1.4 configure.in
> --- configure.in	10 Feb 2004 12:56:21 -0000	1.4
> +++ configure.in	17 Nov 2005 09:13:45 -0000
>  <at>  <at>  -880,8 +880,10  <at>  <at> 
>  # For the host machine, we save the xm_file variable as host_xm_file;
>  # then we decode the target machine and forget everything else
>  # that came from the host machine.
> +arg_with_cpu="$with_cpu"
>  for machine in $build $host $target; do
>  	. ${srcdir}/config.gcc
> +	with_cpu="$arg_with_cpu"
>  done
>  
>  extra_objs="${host_extra_objs} ${extra_objs}"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Darrin B.Jewell | 18 Nov 2005 02:49
Picon

improving build warnings about SYMTAB_SPACE


Platforms that use dbsym and SYMTAB_SPACE often encounter user
confusion because the symbol table space overflow is a non-fatal
build error that is frequently not noticed until run time, sometimes
long after a system has been up.

The attached patch provides the following changes:
   . Have dbsym explicitly suggest increasing SYMTAB_SPACE when
     an overflow occurs.
   . Make this error a fatal build time error
   . Move the support for dbsym into the MI Makefile.kern.inc,
     conditional upon the SYMTAB_SPACE option being defined in
     the kernel config file.

If there are no objections to these changes, I will proceed
to commit them in a few days.

Thanks,
Darrin
Attachment (makedbsym.diff): text/x-patch, 12 KiB
Permalink | Reply | 0 comments |
headers
Simon Burge | 18 Nov 2005 12:59

MIPS binary sizes with binutils 2.15

Folks,

With binutils 2.15, small binaries have grown to a minimum size of over
64kB.  Here's an older (binutils 2.14) and -current (binutils 2.15) /bin/sync:

  9 -r-xr-xr-x  1 simonb  wheel   8787 Mar 14  2005 sync-old*
 13 -rwxr-xr-x  1 simonb  wheel  69768 Nov 18 08:58 sync-current

This is because as of binutils 2.15 the ELF_MAXPAGESIZE constant changed
from 4kB to 64kB, and the data section is aligned in the linked program
to that pagesize.  At least the binutils 2.15 binary is a sparse file.
The comments in elf32-mips.c describe why this constant changed size:

  /* The SVR4 MIPS ABI says that this should be 0x10000, but Irix 5 uses
     a value of 0x1000, and we are compatible.  */
  #define ELF_MAXPAGESIZE                 0x1000
  ...
  /* The SVR4 MIPS ABI says that this should be 0x10000, and Linux uses
     page sizes of up to that limit, so we need to respect it.  */
  #define ELF_MAXPAGESIZE                 0x10000

The sections leading up to the data section of a -current program show
where this gap is:

 Sections:
 Idx Name          Size      VMA       LMA       File off  Algn
  ...
  11 .rodata       00000050  00400d30  00400d30  00000d30  2**4
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
  12 .copyright    00000064  00400d80  00400d80  00000d80  2**2
(Continue reading)

Permalink | Reply | 3 comments |
headers
Chuck Silvers | 18 Nov 2005 17:10
Favicon

Re: MIPS binary sizes with binutils 2.15

On Fri, Nov 18, 2005 at 10:59:00PM +1100, Simon Burge wrote:
> For at least the 3.0 release I'd like to add one of two changes to
> NetBSD:
> 
>  1) Revert ELF_MAXPAGESIZE back to 0x1000 (4kB)
> 
>  2) Remove the text/data gap.
> 
> Reasons for 1) are "this is the way it's always been" prior to binutils
> 2.15, and so has effectively been tested pretty much forever.
> 
> Reasons for 2) are that this is the way binutils does it now, and that
> it follows the MIPS ELF spec.
> 
> I'm personally leaning towards 1) because even though we will be
> violating the MIPS ELF spec, the implications of are well known because
> we've always violated the spec in this regard, and I don't see it as a
> big change leading up to the NetBSD 3.0 release compared with moving the
> data section directly to the end of the text section.
> 
> Comments?

there's another option, which is what the other VIPT-cache platforms do:
put the text and data right together in the file, but map the page
containing the text/data boundary twice:

sparc:
 10 .rodata       000000e8  00010bd8  00010bd8  00000bd8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 11 .data         0000000c  00020cc0  00020cc0  00000cc0  2**2
(Continue reading)

Permalink | Reply | 2 comments |
headers
Simon Burge | 19 Nov 2005 04:46

Re: MIPS binary sizes with binutils 2.15

Chuck Silvers wrote:

> there's another option, which is what the other VIPT-cache platforms do:
> put the text and data right together in the file, but map the page
> containing the text/data boundary twice:

> 
> sparc:
>  10 .rodata       000000e8  00010bd8  00010bd8  00000bd8  2**3
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  11 .data         0000000c  00020cc0  00020cc0  00000cc0  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
> 
> sparc64:
>  10 .rodata       000000c0  0000000000100c70  0000000000100c70  00000c70  2**3
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  11 .data         00000008  0000000000200d30  0000000000200d30  00000d30  2**3
>                   CONTENTS, ALLOC, LOAD, DATA
> 
> hppa:
>  10 .rodata       00000045  00100bf0  00100bf0  00000bf0  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  11 .copyright    00000064  00100c38  00100c38  00000c38  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  12 .PARISC.unwind 00000100  00100c9c  00100c9c  00000c9c  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  13 .data         00000028  00200d9c  00200d9c  00000d9c  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Laight | 26 Nov 2005 21:20
Picon

gcc options for amd64

I've just discovered that all our amd64 binaries have a large eh_frame
section.  This is data that is used by debuggers for processing exxeptions
(I'd guess C++).  There is no corresponding code....

If all comes about because of the following code in
src/gnu/dist/gcc/gcc/config/i386/i386.c near line 1019

  /* Set the default values for switches whose default depends on TARGET_64BIT
     in case they weren't overwriten by command line options.  */
  if (TARGET_64BIT)
    {
      if (flag_omit_frame_pointer == 2)
        flag_omit_frame_pointer = 1;
      if (flag_asynchronous_unwind_tables == 2)
        flag_asynchronous_unwind_tables = 1;
      if (flag_pcc_struct_return == 2)
        flag_pcc_struct_return = 0;
    }
  else
    {
      if (flag_omit_frame_pointer == 2)
        flag_omit_frame_pointer = 0;
      if (flag_asynchronous_unwind_tables == 2)
        flag_asynchronous_unwind_tables = 0;
      if (flag_pcc_struct_return == 2)
        flag_pcc_struct_return = DEFAULT_PCC_STRUCT_RETURN;
    }

Which enables asynchronous_unwind_tables by default for amd64.
The general comments on these options seem to imply that they would
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Husemann | 1 Dec 2005 08:54
Picon

alloca in libc

Stupid question - shouldn't we use the gcc builtin alloca()?
Some archs seem to have alloca implementations in libc, others don't.

I ask because the recent constifications to execl*.c made them use alloca
on sparc64, and sparc64 has no libc alloca implementation.

So the other part of the question - why is gcc not using the builtin when
complinig libc?

Martin
Permalink | Reply | 5 comments |
headers
Juergen Hannken-Illjes | 1 Dec 2005 09:04
Picon
Picon
Favicon

Re: alloca in libc

On Thu, Dec 01, 2005 at 08:54:21AM +0100, Martin Husemann wrote:
> Stupid question - shouldn't we use the gcc builtin alloca()?
> Some archs seem to have alloca implementations in libc, others don't.
> 
> I ask because the recent constifications to execl*.c made them use alloca
> on sparc64, and sparc64 has no libc alloca implementation.

dito for at least sparc and evbppc

> So the other part of the question - why is gcc not using the builtin when
> complinig libc?
> 
> Martin

--

-- 
Juergen Hannken-Illjes - hannken <at> eis.cs.tu-bs.de - TU Braunschweig (Germany)
Permalink | Reply | 0 comments |

Gmane