Path: utzoo!attcan!uunet!world!decwrl!ucbvax!zardoz.coral.com!don
From: don@zardoz.coral.com (Don Dewar)
Newsgroups: comp.lang.c++
Subject: Problems with g++ on a Sun 4 running SunOs4.1
Message-ID: <9010021234.AA04968@zardoz.noname>
Date: 2 Oct 90 12:34:12 GMT
References: <6536@castle.ed.ac.uk>
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 75


) Return-Path: <info-g++-request@prep.ai.mit.edu>
) Date: 1 Oct 90 12:40:39 GMT
) From: uunet!mcsun!ukc!edcastle!mfg  (M Gordon)
) Organization: Edinburgh University Electrical Engineering
) Subject: Problems with g++ on a Sun 4 running SunOs4.1
) Sender: uunet!prep.ai.mit.edu!info-g++-request
) To: info-g++@prep.ai.mit.edu
) 
) I recently posted a message about my problems with g++. Further efforts have
) revealed that the problem is almost certainly with gcc-ld. With this program in
) place programs compiled with gcc give the same results as those compiled with
) g++, i.e. segmentation fault and core dump in start(). Deleting this and going
) back to using the standard linker makes gcc work again. Unfortunately the
) standard linker gives "undefined symbol" errors for ___CTOR_LIST__ and
) ___DTOR_LIST__ when used with g++. Gcc-ld doesn't but I don't understand why -
) I can't find any mention of them in the source for gcc-ld.
) 
) Any help appreciated.
) 
) -- 
) 							 _   _   _    _   _	
) Michael Gordon - mfg@castle.ed.ac.uk OR ee.ed.ac.uk	| |_| |_| |__| |_| |   
) 							| . . . .      . . |    
) I spilt spot remover on my dog and now he's gone! 	|_________|~~|_____|    
) 
) 


Boy was my last message wrong!!!  I didn't attempt to run the correct
executable that resulted from the new gcc-ld.  Just like yours, my
gcc-ld built on a sparcstation running 4.1 also bombed as soon as I
attempt to execute the program.  Anyway, I put the program in the
debugger, and it never gets out of the starting gate.

The gdb session  is:

Current directory is /usr/don/NMS/nobject/
GDB 3.5, Copyright (C) 1989 Free Software Foundation, Inc.
There is ABSOLUTELY NO WARRANTY for GDB; type "info warranty" for details.
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "info copying" to see the conditions.
Reading symbol data from /usr/don/NMS/nobject/nobject...done.
r nmsdbdon
Setting environment variable "ING_SET" to null value.
Type "help" for a list of commands.
(gdb) Starting program: /usr/don/NMS/nobject/nobject nmsdbdon

Program received signal 11, Segmentation fault
0x20 in start ()
(gdb) bt
#0  0x20 in start ()
Error reading memory address 0x20: I/O error (5).
(gdb) 


It looks as though the address of start is bogus.  In the program that
works, the address of start is 0x2020.  I tried looking for these
numbers 2020 and 20 in the system includes and in the g++ sources.  I
didn't find anything that looked like it would have an affect in the
system, but there are some intersting bit operations on tm.h and
something calld tp-s_flag in ld.c.  I don't know enough about this
code or linkers in general to continue, but perhaps this is enough to
get someone more knowledgeable started.

  +---------+
  | Coral   |
  |@@@@@*@**|
  |@@*@@**@@|     Don Dewar
  |*@@**@@@@|     Coral Network Corporation, Marlborough, MA
  |@***@@@@@|     Internet: don@coral.com
  |@@**@@@@@|     Phone:    (508) 460-6010
  |*********|     Fax:      (508) 481-6258
  |Networks |
  +---------+