This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
other/5329: Profiling doesn't work under Solaris 8 x86 - executable cores.
- From: sclift at dtsi dot com
- To: gcc-gnats at gcc dot gnu dot org
- Date: 9 Jan 2002 06:19:39 -0000
- Subject: other/5329: Profiling doesn't work under Solaris 8 x86 - executable cores.
- Reply-to: sclift at dtsi dot com
>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: