egcs 970828 and X11 on linux/x86

egcs 970828 and X11 on linux/x86

[H.J. Lu]

Hi,

On linux/x86, I bootstapped egcs 970828 with -O -g and used that egcs
to compile egcs with -O6 -fomit-frame-pointer. Then I used that
compiler to compile XFree86 3.3.1 with -O6 -fno-exceptions. I didn't
see any problems with the rebuilt XFree86 3.3.1.

BTW, I applied Jim's patch to i386.c:

Wed Aug 27 14:52:54 1997  Jim Wilson  

	* i386.c (ix86_expand_epilogue): Emit blockage instruction when pic.

Without it, shared libraries may be miscompiled with -O2/-O3 or above.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Shared C++ libs on i386-pc-solaris2.5.1

[James Macnicol]

Hello,

	Has anyone managed to build egcs under Solaris x86 2.5.1?
I cannot get any shared C++ libraries to link (including the
libstdc++.so that is built as part of the distribution -- see below),


make[2]: Leaving directory `/export/home/opt/egcs-970828/libio'
/export/home/opt/egcs-970828/gcc/xgcc
-B/export/home/opt/egcs-970828/gcc/ -g -O2 -fno-implicit-templates -h
libstdc++.so.2.8.0 -shared -o libstdc++.so.2.8.0 `cat piclist` -lm
Text relocation remains                       referenced
    against symbol                  offset      in file
__eh_type                           0xe3       
/export/home/opt/egcs-970828/gcc/libgcc.a(_eh.o)
__eh_type                           0x36a      
/export/home/opt/egcs-970828/gcc/libgcc.a(exception.o)
[snip]
__eh_cleanup                        0x243      
/export/home/opt/egcs-970828/gcc/libgcc.a(exception.o)
[snip]
__eh_in_catch                       0x448      
/export/home/opt/egcs-970828/gcc/libgcc.a(exception.o)
__get_dynamic_handler_chain         0x50a      
/export/home/opt/egcs-970828/gcc/libgcc.a(tinfo.o)
[snip]
__terminate                         0x325      
/export/home/opt/egcs-970828/gcc/libgcc.a(exception.o)
[snip]
__sjthrow                           0x24c      
/export/home/opt/egcs-970828/gcc/libgcc.a(exception.o)
[snip]

There are a lot more errors than this, including references to stdc
things
malloc, free etc.  I just tried did a normal configure with
--enable-shared
and let it run (I built gcc in three stages by hand since make from
the toplevel directory doesn't seem to do that).  I am using the
standard
Sun assembler and linker (I realize C++ debugging won't work but I can
live with that for now).

Any ideas?


--
James Macnicol
J.Macnicol@student.anu.edu.au
http://goblet.anu.edu.au/~m9305357/home.html

Small patch for NetBSD

[Allen Briggs]

NetBSD declares sys_errlist--this caused the texinfo compile to break
since it also declares sys_errlist (for mystrerror()).  I won't bother
sending in a patch for that since I compiled the current texinfo with
no trouble recently.  However,

NetBSD has defined sys_siglist since version 1.0.  Here is a patch
that allows the 970828 collect2.c to compile when configured for
m68k-unknown-netbsd1.2g:

Sun Aug 31 11:38:55 1997  Allen Briggs (briggs@macbsd.com)

	* netbsd.h: Define DONT_DECLARE_SYS_SIGLIST if >= NetBSD 1.0.

::::::::::::::::::::::::::::::::::::::::::::::::::

*** /tmp/netbsd.h	Sun Aug 31 11:45:24 1997
--- gcc/config/netbsd.h	Sun Aug 31 12:32:20 1997
***************
*** 34,39 ****
--- 34,40 ----
  
  #endif
  
+ #include 
  
  /* Provide a CPP_SPEC appropriate for NetBSD.  Current we just deal with
     the GCC option `-posix'.  */
***************
*** 65,70 ****
--- 66,78 ----
  #define SWITCH_TAKES_ARG(CHAR) \
    (DEFAULT_SWITCH_TAKES_ARG(CHAR) \
     || (CHAR) == 'R')
+ 
+ /* NetBSD 1.0 and later have sys_siglist in signal.h, but current
+    numbering drops the last digit (i.e., numbering is now YYYYMM). */
+ 
+ #if (NetBSD > 1993070 || NetBSD 

Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')

[Kamil Iskra]

On Sat, 30 Aug 1997, Jim Wilson wrote:

> 	The following code gives a strange warning.
> 	~/Prog> g++ -Wall -O -c egcs-feature2.cc
> 	egcs-feature2.cc: In function `void f()':
> 	egcs-feature2.cc:15: warning: variable `int maxrows' might be clobbered by
> 	`longjmp' or `vfork'
[snip]
> This can probably be fixed by making the sjlj EH support and flow interact
> better.

Actually, is this particular warning a really useful feature, that saves
people from making a bug every other day? I don't think so. To the
contrary, I've seen it several times and every time it was bogus. Perhaps
it would be better to just get rid of this warning?

/ Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 1.6 GB, 18 MB RAM \
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
| http://student.uci.agh.edu.pl/~iskra                         |
\ PGP public key available via Finger or WWW                   /

Re: Shared C++ libs on i386-pc-solaris2.5.1

[Richard Henderson]

> On some systems (PAs running hpux), you can't have a text/readonly data
> item which is initialized to the address of another item.
> 
> ie
> 
> 	.word foo
> 
> isn't valid if it's going into the text or readonly data section.

This is not the case on an i386 ELF system.

In the main application there is a nasty hack called .dynbss which the
linker creates to hold all of the variable references.  So the symbols
are really at constant addresses, and have their contents filled in at
run time.  (It is odeious and breaks when symbol sizes (read arrays)
change.)

A shared library, on the other hand, is tagged with DT_TEXTREL which
tells the loader that it should temporarily remap everything read-write.
Thus, while outputting read-only data that contains relocactions should
be avoided (because of the mprotect penalty), it does function correctly.

All this is if course how things are _supposed_ to work.  If you've got
a broken loader on some system...


r~

Re: Shared C++ libs on i386-pc-solaris2.5.1

[Jeffrey A Law]

  In message < 34174E74.7057@bohm.anu.edu.au >you write:
  > > Gcc is emitting a reference to __ctype into the constant pool.  This is
  > > a place where constants are stored if they aren't valid as immediates in
  > > an instruction.  This is for instance where floating point constants are
  > > stored.
[ ... ]
  > > 
  > > Tue Sep  9 16:29:42 1997  Jim Wilson  <wilson@cygnus.com>
  > > 
  > >         * i386/sco5.h (READONLY_DATA_SECTION): Define.
[ ... ]

  > 	Alas, this isn't the solution for i386-pc-solaris2.5.1.
  > READONLY_DATA_SECTION() is already defined as above in 
  > gcc/config/i386/svr4.h which is included in the Solaris x86 config.
Hmmmm.

On some systems (PAs running hpux), you can't have a text/readonly data
item which is initialized to the address of another item.

ie

	.word foo

isn't valid if it's going into the text or readonly data section.

This is becaue the dynamic linker can't modify that memory location
at runtime if "foo" is resolved from a shared library.

Maybe you're running into a similar problem.

Jeff

Re: Shared C++ libs on i386-pc-solaris2.5.1

[James Macnicol]

>         -Tcl 8.0 will not build with egcs-970904 since "__ctype" is not found
>         by
>         the linker.  Tcl 8.0 compiles fine with gcc 2.7.2.2.
> 
> I was just discussing a similar problem with one of the i386-sco5 users.
> Was this a shared library build?  The following info may be useful.
> 
> --
> 
> Gcc is emitting a reference to __ctype into the constant pool.  This is
> a place where constants are stored if they aren't valid as immediates in
> an instruction.  This is for instance where floating point constants are
> stored.
> 
> This is happening because of a change to the cse pass, which is causing
> some constants to be forced into the constant pool that weren't before.
> This is a somewhat questionable optimization, since it may increase the
> size of the program without giving faster code.  In any case, if you compile
> with -O2, the constant pool itself is optimized, and unused constants are
> removed.  So this problem goes away at -O2.
> 
> This constant pool entry should have gone into the the readonly data section
> (or into the data section), instead of the default text section.
> 
> This change was copied from the svr4.h file, so I suspect that it will
> fix your problem.
> 
> If not, then try the definition of SELECT_RTX_SECTION from sparc/sysv4.h.
> This will put the constant pool entry into the data section.
> 
> Tue Sep  9 16:29:42 1997  Jim Wilson  <wilson@cygnus.com>
> 
>         * i386/sco5.h (READONLY_DATA_SECTION): Define.
> 
> Index: sco5.h
> ===================================================================
> RCS file: /cvs/cvsfiles/egcs/gcc/config/i386/sco5.h,v
> retrieving revision 1.1.1.1
> diff -p -r1.1.1.1 sco5.h
> *** sco5.h      1997/08/11 15:57:18     1.1.1.1
> --- sco5.h      1997/09/09 23:27:54
> *************** do {                                                                    \
> *** 573,578 ****
> --- 573,580 ----
>     CTORS_SECTION_FUNCTION                                              \
>     DTORS_SECTION_FUNCTION
> 
> + #define READONLY_DATA_SECTION() const_section ()
> +
>   #undef CONST_SECTION_FUNCTION
>   #define CONST_SECTION_FUNCTION                                                \
>   void                                                                  \

	Alas, this isn't the solution for i386-pc-solaris2.5.1.
READONLY_DATA_SECTION() is already defined as above in 
gcc/config/i386/svr4.h which is included in the Solaris x86 config.

	Rebuilding Tcl 8.0 with -O2 also does not remove the
error.

	Something I forgot in the original post was to say that
gcc/objc/archive.c needs a dose of <stdarg.h> to pick up the va_*
macros.



James

Re: Shared C++ libs on i386-pc-solaris2.5.1

[James Macnicol]

>         -I had problems with compiling a certain file in my current project
>         since the machine would start thrashing and eventually say "virtual
>         memory
>         exhausted".  I traced it to a C++ header file which had an inline member
>         function; moving that out of the header and into the implementation
>         solved
>         the problem.  On a better note, this project now builds without the
>         internal
>         compiler errors it has with gcc 2.7.2.2.
> 
> I don't know enough about C++ to handle C++ specific problems.  If you
> submit a testcase, you might be able to get a response from one of the
> other volunteers.

	I have since determined it's an STL-related problem.  Even in
implementation files, calls to the push_back member of "list" cause
this problem.  The cases I have seen are when pushing types I have
written (i.e. not standard types).  I'm sorry I can't give any more
detail than that at this stage.  I'll see if I can come up with
something.

	I will report tomorrow on the shared libraries stuff with
Tcl on Solaris x86.



James


P.S.  My apologies to Jim Wilson .... I meant the last message to go
to the list, not to him personally.  I will check my To: and Cc:
lines more carefully next time.

Re: Shared C++ libs on i386-pc-solaris2.5.1

[H.J. Lu]

> 
> -	Doing make -j4 MAKE="make -j4" for the egcs build (i.e. a parallel
> build)
> still causes problems although it seems better than the previous
> releases I
> tried to build.
> 

I have no problems with -j 6 on my SMP box. But I have sent in
quite a few patches to fix it. Among them, 2 are left out:


Tue Aug 26 07:43:18 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

        * Makefile.in (check-g++): Set/export LD_LIBRARY_PATH if necessary.
        (testsuite/site.exp): New target.
        (check-gcc, check-g++): Depend on testsuite/site.exp.
        Don't stop for failure.

Mon Aug 25 17:31:49 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

        * Makefile (all): Remove sub-all.
        (stmp-sub-all): New target. Renamed from sub-all.
        (info, texinfo): Also depend on stmp-sub-all.
        (clean): Also remove stmp*.
        (maintainer-clean): New target. Same as realclean.

If you check egcs archive, you should be able to find them.



H.J.

Re: Shared C++ libs on i386-pc-solaris2.5.1

[James Macnicol]

>        Has anyone managed to build egcs under Solaris x86 2.5.1?
>        I cannot get any shared C++ libraries to link (including the
>        libstdc++.so that is built as part of the distribution -- see below),
>
>Looks like this is a bug in the gcc x86/solaris support.  The shared library
>support is not completely correct (a common problem).  I do not have access
>to such a system, so I can't be sure what the correct fix is.  However, just
>comparing against the sparc/solaris support, I am guessing that libgcc.a was
>not compiled PIC.
>
>Does this patch solve your problem?

	Sure does.  Thanks!

	I have now successfully built egcs 970904 on Solaris x86 2.5.1.  Some
comments/observations I have are :

-	I had problems with compiling a certain file in my current project
since the machine would start thrashing and eventually say "virtual
memory
exhausted".  I traced it to a C++ header file which had an inline member
function; moving that out of the header and into the implementation
solved
the problem.  On a better note, this project now builds without the
internal
compiler errors it has with gcc 2.7.2.2.

-	Doing make -j4 MAKE="make -j4" for the egcs build (i.e. a parallel
build)
still causes problems although it seems better than the previous
releases I
tried to build.

-	Tcl 8.0 will not build with egcs-970904 since "__ctype" is not found
by
the linker.  Tcl 8.0 compiles fine with gcc 2.7.2.2.



Thanks.


James


--
James Macnicol
J.Macnicol@student.anu.edu.au
http://goblet.anu.edu.au/~m9305357/home.html

Re: Shared C++ libs on i386-pc-solaris2.5.1

[Jeffrey A Law]

  In message < 199709042205.PAA24609@cygnus.com >you write:
  > Looks like this is a bug in the gcc x86/solaris support.  The shared library
  > support is not completely correct (a common problem).  I do not have access
  > to such a system, so I can't be sure what the correct fix is.  However, just
  > comparing against the sparc/solaris support, I am guessing that libgcc.a was
  > not compiled PIC.
  > 
  > Does this patch solve your problem?
  > 
  > Thu Sep  4 15:02:27 1997  Jim Wilson  <wilson@cygnus.com>
  > 
  > 	* i386/t-sol2 (TARGET_LIBGCC2_CFLAGS): Define to -fPIC.
I'm pretty sure this is the right fix...  Even if some problems remain.

I went ahead and installed it.

jeff

Re: Shared C++ libs on i386-pc-solaris2.5.1

[Jim Wilson]

	Has anyone managed to build egcs under Solaris x86 2.5.1?
	I cannot get any shared C++ libraries to link (including the
	libstdc++.so that is built as part of the distribution -- see below),

Looks like this is a bug in the gcc x86/solaris support.  The shared library
support is not completely correct (a common problem).  I do not have access
to such a system, so I can't be sure what the correct fix is.  However, just
comparing against the sparc/solaris support, I am guessing that libgcc.a was
not compiled PIC.

Does this patch solve your problem?

Thu Sep  4 15:02:27 1997  Jim Wilson  <wilson@cygnus.com>

	* i386/t-sol2 (TARGET_LIBGCC2_CFLAGS): Define to -fPIC.

Index: t-sol2
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/config/i386/t-sol2,v
retrieving revision 1.1.1.1
diff -p -r1.1.1.1 t-sol2
*** t-sol2	1997/08/11 15:57:17	1.1.1.1
--- t-sol2	1997/09/04 22:02:12
*************** crtn.o: $(srcdir)/config/i386/sol2-cn.as
*** 33,35 ****
--- 33,36 ----
  # routines in crtstuff.c.
  
  CRTSTUFF_T_CFLAGS = -fPIC
+ TARGET_LIBGCC2_CFLAGS = -fPIC