Re: other/5329: Profiling doesn't work under Solaris 8 x86 - executable cores.

Re: other/5329: Profiling doesn't work under Solaris 8 x86 - executable cores.

[steven]

Synopsis: Profiling doesn't work under Solaris 8 x86 - executable cores.

State-Changed-From-To: open->feedback
State-Changed-By: steven
State-Changed-When: Tue May 13 06:49:36 2003
State-Changed-Why:
    Probably can be closed, but the reporter is checking that.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5329

Re: other/5329: Profiling doesn't work under Solaris 8 x86 - executable cores.

[Dara Hazeghi]

The following reply was made to PR other/5329; it has been noted by GNATS.

From: Dara Hazeghi <dhazeghi@yahoo.com>
To: sclift@dtsi.com, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: other/5329: Profiling doesn't work under Solaris 8 x86 - executable cores.
Date: Mon, 12 May 2003 18:06:31 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=5329
 
 Hello,
 
 gcc 3.0.3 is rather old. Would it be possible for you to check whether  
 this problem is still present in a more current version of gcc (ie  
 3.2.3 or the soon-to-be-released 3.3)? Thanks,
 
 Dara
 

other/5329: Profiling doesn't work under Solaris 8 x86 - executable cores.

[sclift]

>Number:         5329
>Category:       other
>Synopsis:       Profiling doesn't work under Solaris 8 x86 - executable cores.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 08 22:26:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Steve Clift
>Release:        2.95.1 through 3.0.3 at least
>Organization:
>Environment:
Reading specs from /usr/local/GCC-3.0.2/lib/gcc-lib/i386-pc-solaris2.8/3.0.3/specs
Configured with: /tmp/gcc/gcc-3.0.1/configure --prefix=/usr/local/GCC-3.0.2 : (reconfigured) 
Thread model: posix
gcc version 3.0.3
>Description:
Profiling doesn't work under Solaris 8 x86. Programs compiled with the
-pg option core dump in the _init() routine. This holds for GCC 2.95.2,
2.95.3, 3.0.2 and 3.0.3 at least. I think it has something to do with
the way GCC links the program. There are some .init sections in
/usr/lib/libp/libc.a (and possibly elsewhere) that are collected in the
_init() routine, generating a sequence of calls to initialisation
functions. It seems that alignment of the call instructions is done by
padding with zero bytes rather than NOPS. Two zeros equals an "add
%al,(%eax)", which is not good. Here are disassembled _init()s obtained
by compiling and "main(){}":

Compiled with "cc -o zz -pg zz.c"

section        .init
_init()
        806d8b0:  e8 4b 2d fe ff      call   frame_dummy
        806d8b5:  90                  nop    
        806d8b6:  90                  nop    
        806d8b7:  90                  nop    
        806d8b8:  90                  nop    
        806d8b9:  90                  nop    
        806d8ba:  90                  nop    
        806d8bb:  90                  nop    
        806d8bc:  90                  nop    
        806d8bd:  90                  nop    
        806d8be:  90                  nop    
        806d8bf:  90                  nop    
        806d8c0:  e8 a3 2d fe ff      call   _atexit_init
        806d8c5:  e8 e6 4c fe ff      call   check_nlspath_env
        806d8ca:  00 00               addb   %al,(%eax)
        806d8cc:  00 00               addb   %al,(%eax)
        806d8ce:  00 00               addb   %al,(%eax)
        806d8d0:  e8 8b ff ff ff      call   __do_global_ctors_aux
        806d8d5:  90                  nop    
        806d8d6:  90                  nop    
        806d8d7:  90                  nop    
        806d8d8:  90                  nop    
        806d8d9:  90                  nop    
        806d8da:  90                  nop    
        806d8db:  90                  nop    
        806d8dc:  90                  nop    
        806d8dd:  90                  nop    
        806d8de:  90                  nop    
        806d8df:  90                  nop    
        806d8e0:  c2 00 00            ret    $0x0

Compiled with "cc -o zz zz.c"

section        .init
_init()
	8050710:  e8 57 ff ff ff      call   frame_dummy
	8050715:  90                  nop    
	8050716:  90                  nop    
	8050717:  90                  nop    
	8050718:  90                  nop    
	8050719:  90                  nop    
	805071a:  90                  nop    
	805071b:  90                  nop    
	805071c:  90                  nop    
	805071d:  90                  nop    
	805071e:  90                  nop    
	805071f:  90                  nop    
	8050720:  e8 a3 ff ff ff      call   __do_global_ctors_aux
	8050725:  90                  nop    
	8050726:  90                  nop    
	8050727:  90                  nop    
	8050728:  90                  nop    
	8050729:  90                  nop    
	805072a:  90                  nop    
	805072b:  90                  nop    
	805072c:  90                  nop    
	805072d:  90                  nop    
	805072e:  90                  nop    
	805072f:  90                  nop    
	8050730:  c2 00 00            ret    $0x0

Deleting /usr/lib/libp/libc.a fixes the problem, presumably by forcing the
linker to use /usr/lib/libc.a instead. The resulting _init() is the same
as if -pg was not used. Nasty solution, though.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: