strange compile problem

strange compile problem

[John Barry]

Hi,

I'm getting this error when I try to build binutils-2.9.5.0.12 with gcc-2.95.1
(compiled for/on a native utrasparc running Solaris 2.6)

SunOS xxx 5.6 Generic_105181-05 sun4u sparc

gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.9.5.0.12/gprof -I. -D_GNU_SOURCE -DDEBUG -I../bfd -I../../binutils-2.9.5.0.12/gprof/../include -I../../binutils-2.9.5.0.12/gprof/../bfd -I../../binutils-2.9.5.0.12/gprof/../intl -I../intl -DLOCALEDIR="\"/apps/gnu2/share/locale\""  -I/usr/openwin/include -I/usr/dt/include -I/apps/include -I/apps/gnu/include -I/apps/X11R6/include -I/apps/gnome/include -I/apps/kde/include -I/apps/ImageMagick/include  -O3 -funroll-loops -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -c ../../binutils-2.9.5.0.12/gprof/hist.c
/var/tmp/ccUupNBD.s: Assembler messages:
/var/tmp/ccUupNBD.s:1963: Error: Illegal operands
/var/tmp/ccUupNBD.s:1986: Error: Illegal operands
/var/tmp/ccUupNBD.s:2008: Error: Illegal operands
/var/tmp/ccUupNBD.s:2100: Error: Illegal operands
*** Error code 1
make: Fatal error: Command failed for target `hist.o'
Current working directory /apps/jbarry/gnu/gcc/bin-build/gprof

This error goes away if I remove the optimisation flag  completeley, (even
with -O it still give me assembler errors) but I have my doubts about the 
correctness of the code produced in this manner.

This error is reproducable on my system with both a full build:

#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
../binutils-2.9.5.0.12/configure --host=sparc-sun-solaris2.6 --prefix=/apps/gnu2
 --enable-shared --enable-static --enable-bfd-assembler --enable-commonbfdlib --
enable-64-bit-bfd --with-included-gettext --enable-targets=all --enable-multilib
 --enable-threads=posix --with-cpu=ultrasparc --norecursion 
# using "mh-frag" and "mt-frag"

and with a seperate config in the gprof dir thus:

# configure  --prefix=/apps/gnu2 --enable-shared --enable-static --with-included
-gettext --with-x --x-includes=/usr/openwin/include --x-libraries=/usr/openwin/l
ib

I'm including the compile flags -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64
as recommended by Sun to ensure the apps are compliant with 2.6's 64 file
system, it make no difference if I take them out or not, the only thing that
affects it is -O (or not...)

as and ld are gnu-as & gnu-ld from binutils-2.9.1, but I've been getting screwy
errors out the compiler for a few days so I decided to see if upgrading
binutils would help...

I didn't have these problems with the egcs-1.1.2 release, any ideas?

later
jb
----
John Barry
Unix Network Administrator
European Southern Observatory
Karl-Schwarzschild-Strasse 2
D-85748 Garching b. Munchen
Germany

Re: strange compile problem

[Ian Lance Taylor]

   From: John Barry <jbarry@eso.org>
   Date: Mon, 13 Sep 1999 15:53:00 +0200 (MET DST)

   I'm getting this error when I try to build binutils-2.9.5.0.12 with gcc-2.95.1
   (compiled for/on a native utrasparc running Solaris 2.6)

   SunOS xxx 5.6 Generic_105181-05 sun4u sparc

   gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.9.5.0.12/gprof -I. -D_GNU_SOURCE -DDEBUG -I../bfd -I../../binutils-2.9.5.0.12/gprof/../include -I../../binutils-2.9.5.0.12/gprof/../bfd -I../../binutils-2.9.5.0.12/gprof/../intl -I../intl -DLOCALEDIR="\"/apps/gnu2/share/locale\""  -I/usr/openwin/include -I/usr/dt/include -I/apps/include -I/apps/gnu/include -I/apps/X11R6/include -I/apps/gnome/include -I/apps/kde/include -I/apps/ImageMagick/include  -O3 -funroll-loops -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -c ../../binutils-2.9.5.0.12/gprof/hist.c
   /var/tmp/ccUupNBD.s: Assembler messages:
   /var/tmp/ccUupNBD.s:1963: Error: Illegal operands
   /var/tmp/ccUupNBD.s:1986: Error: Illegal operands
   /var/tmp/ccUupNBD.s:2008: Error: Illegal operands
   /var/tmp/ccUupNBD.s:2100: Error: Illegal operands
   *** Error code 1
   make: Fatal error: Command failed for target `hist.o'
   Current working directory /apps/jbarry/gnu/gcc/bin-build/gprof

This sounds more like a compiler problem than a binutils problem.  On
the other hand, since you are using an UltraSPARC, it is quite
possible that you need some UltraSPARC support added since the 2.9.1
release.

To check that, run the above command with the --save-temps option, and
take a look at the resulting assembler file.  Send it in here if you
want to, or better yet just send the lines that the assembler is
complaining about.

Even though you are compiling the binutils code itself, it's much
easier for you to send a test case than it is for us to try to
duplicate your compiler.

Ian

Re: strange compile problem

[John Barry]

Hi,

> >    I've been getting this with every version of binutils I've built up since I
> >    started using -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64, this includes
> >    2.9.1 and every snapshop I've downloaded from cygnus. It's a Solaris only
> >    issue, didn't happen when I built it on a hppa2.0 Visualise C 3000
> > 
> > You can probably fix it by adding
> > 
> > #include <sys/types.h>
> > #include <sys/stat.h>
> > 
> > near the top of bfd/bfd-in2.h.
> > 
> > I'm somewhat uncomfortable with requiring every program which includes
> > bfd.h to also include those files.  Unfortunately, the only other
> > choice is probably to change the two uses of struct stat * to void *,
> > instead, and thus lose type checking.
> 
> I would be inclined to warn away from this.  In fact, I think something
> more comprehensive needs to be done in people are using -D_FILE_OFFSET_BITS=64.
> (Note that newer glibc versions also support this, not just Solaris.)
> 
> Since bfd_stat is a user-visible function in -lbfd, the type used in its
> interface needs to be well-specified for all users for the library, not
> just code in the binutils tree.

Well, it has to be said that Solaris isn't that hot on 64bit, 2.6 is reckoned
to have a 64bit FS, but just try building gdb with -D_FILE_OFFSET_BITS=64,
(any version) it bombs out whenever you include <sys/procfs.h>:

#if _FILE_OFFSET_BITS == 64
#error  "Cannot use procfs in the large file compilation environment"
#endif

At which point the bfd.h code:

	struct stat;
	struct stat64;
	#if _FILE_OFFSET_BITS - 0 == 64
	#define bfd_stat bfd_stat64
	#else
	extern int bfd_stat64 PARAMS ((bfd *abfd, struct stat64 *));
	#endif
	extern int bfd_stat PARAMS ((bfd *abfd, struct stat *));

Wouldn't do you a lot of good, since you have to remove the _FILE_OFFSET flag
to get more than a few object files to build at all, (it was gdb's failure to
build that caused me to rethink, in the first place...)

Food for thought.

later
jb

Re: strange compile problem

[Roland McGrath]

On the other hand, I see that bfd_stat is the only thing in bfd.h that
incurs the wrath of _FILE_OFFSET_BITS.  The only other related concern is
off_t vs `file_ptr', which has been circumvented already by just always
using `long int' for `file_ptr'.  As long as the internal conversions to
whatever type off_t is happen properly, I think that is fine.  I mean,
anyone on the list wanted to operate on a file >=2GB with BFD so far in life?

That being the case, I'd be most inclined to just punt bfd_stat from the
interface entirely.  If anyone needs to do that, it's much simpler to
provide a function that returns the fd (or FILE *) they can stat themselves.
Naturally that opens the door to people doing stupid things with that fd
behind BFD's back, but I am certainly willing to say "don't do that" (just
as you can't diddle much with an fd behind stdio's back and expect life not
to go to hell).

Re: strange compile problem

[Roland McGrath]

>    From: John Barry <jbarry@eso.org>
>    Date: Mon, 13 Sep 1999 20:49:34 +0200 (MET DST)
> 
>    >    ../../binutils-2.9.5.0.12/bfd/libbfd.c: In function `bfd_stat':
>    >    ../../binutils-2.9.5.0.12/bfd/libbfd.c:638: argument `statbuf' doesn't match prototype
>    >    ../../binutils-2.9.5.0.12/bfd/bfd.h:482: prototype declaration
>    > 
>    >    extern int bfd_stat PARAMS ((bfd *abfd, struct stat *));
>    > 
>    > I don't see that with the current development sources.  Do you see it
>    > with the snapshot from the Cygnus site, or just with 2.9.5.0.12 (which
>    > is a GNU/Linux specific release)?
> 
>    I've been getting this with every version of binutils I've built up since I
>    started using -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64, this includes
>    2.9.1 and every snapshop I've downloaded from cygnus. It's a Solaris only
>    issue, didn't happen when I built it on a hppa2.0 Visualise C 3000
> 
> You can probably fix it by adding
> 
> #include <sys/types.h>
> #include <sys/stat.h>
> 
> near the top of bfd/bfd-in2.h.
> 
> I'm somewhat uncomfortable with requiring every program which includes
> bfd.h to also include those files.  Unfortunately, the only other
> choice is probably to change the two uses of struct stat * to void *,
> instead, and thus lose type checking.

I would be inclined to warn away from this.  In fact, I think something
more comprehensive needs to be done in people are using -D_FILE_OFFSET_BITS=64.
(Note that newer glibc versions also support this, not just Solaris.)

Since bfd_stat is a user-visible function in -lbfd, the type used in its
interface needs to be well-specified for all users for the library, not
just code in the binutils tree.

The -D_FILE_OFFSET_BITS=64 setting changes the meaning of `struct stat' in
the source code (along with off_t et al, and which libc functions you get
for fstat et al).  So, the same setting must be used when building libbfd
and when building anything to be linked against libbfd.

Note that -D_LARGEFILE64_SOURCE=1 gives you a parallel set of `struct stat64',
off64_t, fstat64, et al.  So this makes it always possible to use the 64-bit
types, even in 32-bit mode (i.e. _FILE_OFFSET_BITS=32, which is usually the
default).  As far as I am aware, there is no *32 set of names--so there is no
way you can use the 32-bit types when in _FILE_OFFSET_BITS=64 mode.

Since this two-way 32/64-bit interface is quickly taking over the world, I
think the bfd interface should address it directly in some way.  Otherwise
there will just be mayhem as people try to choose what flavor to compile their
world and figure out how each libbfd they install was compiled.

The simplest alternative, naturally, is the official "Don't do that"; that is,
let it be said that if thy compiler configuration and precise set of tweaky
compatibility options of which they define a new one every three and half
minutes, used to compile a bfd-using program, strays in the slightest from
that used to compiled bfd, ye shall be smote.  And if bfd was compiled by thy
vendor and thou knowest not what the bleeding hell they did, just consider
thyself preemptively smote on principle.

The only reasonable alternative I see is to make bfd fully "LFS-aware", as the
youngin's call it.  It doesn't have to be too painful.  You can refer to both
`struct stat' and `struct stat64' as declared incomplete types, even if in the
end one of them is never defined at all.  bfd.h can do:

	struct stat;
	struct stat64;
	#if _FILE_OFFSET_BITS - 0 == 64
	#define bfd_stat bfd_stat64
	#else
	extern int bfd_stat64 PARAMS ((bfd *abfd, struct stat64 *));
	#endif
	extern int bfd_stat PARAMS ((bfd *abfd, struct stat *));

Then internally, BFD should be compiled with _LARGEFILE64_SOURCE but
_FILE_OFFSET_BITS=32.  bfd_stat takes a (32-bit mode) struct stat,
while bfd_stat64 takes a struct stat64 (which is the same as 64-bit mode's
struct stat).

This should let 32-bit mode callers' source use bfd_stat or bfd_stat64 and get
both flavors, and let 64-bit mode callers' source use bfd_stat for 64-bit
flavor.

Re: strange compile problem

[Ian Lance Taylor]

   From: John Barry <jbarry@eso.org>
   Date: Mon, 13 Sep 1999 20:49:34 +0200 (MET DST)

   >    ../../binutils-2.9.5.0.12/bfd/libbfd.c: In function `bfd_stat':
   >    ../../binutils-2.9.5.0.12/bfd/libbfd.c:638: argument `statbuf' doesn't match prototype
   >    ../../binutils-2.9.5.0.12/bfd/bfd.h:482: prototype declaration
   > 
   >    extern int bfd_stat PARAMS ((bfd *abfd, struct stat *));
   > 
   > I don't see that with the current development sources.  Do you see it
   > with the snapshot from the Cygnus site, or just with 2.9.5.0.12 (which
   > is a GNU/Linux specific release)?

   I've been getting this with every version of binutils I've built up since I
   started using -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64, this includes
   2.9.1 and every snapshop I've downloaded from cygnus. It's a Solaris only
   issue, didn't happen when I built it on a hppa2.0 Visualise C 3000

You can probably fix it by adding

#include <sys/types.h>
#include <sys/stat.h>

near the top of bfd/bfd-in2.h.

I'm somewhat uncomfortable with requiring every program which includes
bfd.h to also include those files.  Unfortunately, the only other
choice is probably to change the two uses of struct stat * to void *,
instead, and thus lose type checking.

Ian

Re: strange compile problem

[John Barry]

Hi,

>    I was trying to compile binutils-2.9.5.0.12, which I found on va-research's 
>    ftp site, it gives me the same kind of problems with the latest snap from
>    cygnus too. Though while I'm on the subject I get a problem building 
>    bfd/libbfd.c it always fails with this error:
> 
>    ../../binutils-2.9.5.0.12/bfd/libbfd.c: In function `bfd_stat':
>    ../../binutils-2.9.5.0.12/bfd/libbfd.c:638: argument `statbuf' doesn't match prototype
>    ../../binutils-2.9.5.0.12/bfd/bfd.h:482: prototype declaration
> 
>    extern int bfd_stat PARAMS ((bfd *abfd, struct stat *));
> 
> I don't see that with the current development sources.  Do you see it
> with the snapshot from the Cygnus site, or just with 2.9.5.0.12 (which
> is a GNU/Linux specific release)?

I've been getting this with every version of binutils I've built up since I
started using -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64, this includes
2.9.1 and every snapshop I've downloaded from cygnus. It's a Solaris only
issue, didn't happen when I built it on a hppa2.0 Visualise C 3000

According to Sun -D_LARGEFILE64_SOURCE=1 give the program a second set of 64
bit registers in addition to the 32bit ones, while the -D_FILE_OFFSET_BITS=64
actually converts the registers to 64 bit on the fly. Check this:

  QUESTION: How do I enable large file support? 
  Nicolai: You have two choices in your application. For transparent conversion of off_t to
  64-bits, you can use _FILE_OFFSET_BITS=64 compile flag. Or you can have Solaris
  give you a second set of 64-bit interfaces alongside the existing 32-bit interfaces. This is
  done by the _LARGEFILE64_SOURCE=1 compile time flag. Don't use "Strinct ANSI"
  mode for the compiler. 

From: http://suncom.bilkent.edu.tr/developers/solaris2.6.html

>    Which I figure is because 2.9.1, et all aren't fully 64bit file system 
>    compliant, (or Solaris 2.6 isn't :) I get around it by removing 
>    -D_FILE_OFFSET_BITS=64 from the compile flags, and leaving -D_LARGEFILE64_SOURCE=1
>    in, seems to work, though a patch would be very welcome :)
> 
> I don't know what has to change in the binutils for them to become
> 64bit file compliant.  I don't really know why anything has to
> change.

Like I said, technically speaking it doesn't, because I can get around it, and I
don't imagine that that many people will take the time and trouble to rebuild
all thier apps for 64 bit compliance. But since we were upgrading the way apps
were distributed, and the bulk of our boxes are now Ultras I figured I'd go the
whole hog and upgrade the lot, stop the users from bitching. :)

later
jb
----
John Barry
Unix Network Administrator
European Southern Observatory
Karl-Schwarzschild-Strasse 2
D-85748 Garching b. Munchen
Germany

Re: strange compile problem

[Ian Lance Taylor]

   From: John Barry <jbarry@eso.org>
   Date: Mon, 13 Sep 1999 19:13:03 +0200 (MET DST)

   I was trying to compile binutils-2.9.5.0.12, which I found on va-research's 
   ftp site, it gives me the same kind of problems with the latest snap from
   cygnus too. Though while I'm on the subject I get a problem building 
   bfd/libbfd.c it always fails with this error:

   ../../binutils-2.9.5.0.12/bfd/libbfd.c: In function `bfd_stat':
   ../../binutils-2.9.5.0.12/bfd/libbfd.c:638: argument `statbuf' doesn't match prototype
   ../../binutils-2.9.5.0.12/bfd/bfd.h:482: prototype declaration

   extern int bfd_stat PARAMS ((bfd *abfd, struct stat *));

I don't see that with the current development sources.  Do you see it
with the snapshot from the Cygnus site, or just with 2.9.5.0.12 (which
is a GNU/Linux specific release)?

   Which I figure is because 2.9.1, et all aren't fully 64bit file system 
   compliant, (or Solaris 2.6 isn't :) I get around it by removing 
   -D_FILE_OFFSET_BITS=64 from the compile flags, and leaving -D_LARGEFILE64_SOURCE=1
   in, seems to work, though a patch would be very welcome :)

I don't know what has to change in the binutils for them to become
64bit file compliant.  I don't really know why anything has to
change.

   > To check that, run the above command with the --save-temps option, and
   > take a look at the resulting assembler file.  Send it in here if you
   > want to, or better yet just send the lines that the assembler is
   > complaining about.

   Here you go :)

   -c --save-temps ../../binutils-2.9.5.0.12/gprof/hist.c

   hist.s:1963: Error: Illegal operands [fbule,a,pn %fcc3, .LL310]
   hist.s:1986: Error: Illegal operands [fbule,a,pn %fcc3, .LL256]
   hist.s:2008: Error: Illegal operands [fbule,a,pn %fcc3, .LL311]
   hist.s:2100: Error: Illegal operands [fbule,a,pn %fcc3, .LL316]

Thanks.  The current development sources do assemble these
instructions correctly when using the -Av9 option.

Ian

Re: strange compile problem

[John Barry]

Hi,

> This sounds more like a compiler problem than a binutils problem.  On

I read a little more of the list after I'd sent my mail, and found someone
who, while reporting a different problem stated the following:

  You can't use 2.9.1 in combination with gcc 2.95.1's option -mcpu=ultrasparc

and since I'd built my gcc-2.95.1 with exactly that I think that what I need to 
do is fall back to egcs 1.1.2 and rebuild gcc (again :( Ah well [sniff]

> the other hand, since you are using an UltraSPARC, it is quite
> possible that you need some UltraSPARC support added since the 2.9.1
> release.

I was trying to compile binutils-2.9.5.0.12, which I found on va-research's 
ftp site, it gives me the same kind of problems with the latest snap from
cygnus too. Though while I'm on the subject I get a problem building 
bfd/libbfd.c it always fails with this error:

../../binutils-2.9.5.0.12/bfd/libbfd.c: In function `bfd_stat':
../../binutils-2.9.5.0.12/bfd/libbfd.c:638: argument `statbuf' doesn't match prototype
../../binutils-2.9.5.0.12/bfd/bfd.h:482: prototype declaration

extern int bfd_stat PARAMS ((bfd *abfd, struct stat *));

Which I figure is because 2.9.1, et all aren't fully 64bit file system 
compliant, (or Solaris 2.6 isn't :) I get around it by removing 
-D_FILE_OFFSET_BITS=64 from the compile flags, and leaving -D_LARGEFILE64_SOURCE=1
in, seems to work, though a patch would be very welcome :)

> To check that, run the above command with the --save-temps option, and
> take a look at the resulting assembler file.  Send it in here if you
> want to, or better yet just send the lines that the assembler is
> complaining about.

Here you go :)

-c --save-temps ../../binutils-2.9.5.0.12/gprof/hist.c

hist.s:1963: Error: Illegal operands [fbule,a,pn %fcc3, .LL310]
hist.s:1986: Error: Illegal operands [fbule,a,pn %fcc3, .LL256]
hist.s:2008: Error: Illegal operands [fbule,a,pn %fcc3, .LL311]
hist.s:2100: Error: Illegal operands [fbule,a,pn %fcc3, .LL316]

> Even though you are compiling the binutils code itself, it's much
> easier for you to send a test case than it is for us to try to
> duplicate your compiler.

Duly noted, cheers for the reply, much appreciated.

later
jb
----
John Barry
Unix Network Administrator
European Southern Observatory
Karl-Schwarzschild-Strasse 2
D-85748 Garching b. Munchen
Germany