Bug 121775 - Gcc is not restoring the global pointer after a memcpy call causing segv.
Gcc is not restoring the global pointer after a memcpy call causing segv.
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: gcc (Show other bugs)
2.1
ia64 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-27 14:16 EDT by Michael Chynoweth
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:22:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test case for this bug. (2.50 KB, text/plain)
2004-04-27 14:18 EDT, Michael Chynoweth
no flags Details
Makefile for testcase (228 bytes, text/plain)
2004-04-30 13:21 EDT, Mike Simons
no flags Details
Test case (1.19 KB, text/plain)
2004-04-30 13:22 EDT, Mike Simons
no flags Details
Sample run (2.63 KB, text/plain)
2004-04-30 13:25 EDT, Mike Simons
no flags Details
Description of the problem (1.13 KB, text/plain)
2004-04-30 13:26 EDT, Mike Simons
no flags Details

  None (edit)
Description Michael Chynoweth 2004-04-27 14:16:45 EDT
Description of problem:
Problem Statement:

The compiler gcc-c++-2.96-124.7.2 is producing incorrect code for the 
source contained within test.cc through not restoring the global 
pointer after a call to memcpy.

A call to memcpy is made in libc.  The global pointer is set to the 
correct value to point at the center of the static/global short data 
section for that shared object.  When the call returns it attempts to 
do a offset from the global pointer for a load and crashes because it 
has returned to the test executable where the stale global pointer is 
not longer valid.

br.call.sptk.many b0 = memcpy#  // Call to memcpy
	;;
[.LBE3:]
	addl r15 = @gprel(_.tmp_0.13#), gp 	//gp rel addr. used 
						//Before gp restored
	;;
	st4 [r15] = r118			//Crash occurs here 
	.loc 1 58 0
	br .L2
.L6:


Version-Release number of selected component (if applicable):
gcc-c++-2.96-124.7.2 

How reproducible:
Everytime

Steps to Reproduce:
1. run make on example provided
2. make test.s to view the issue in the assembly
3.
  
Actual results:
Segmentation violation

Expected results:
Global pointer should be restored.

Additional info:

Questions:
Please contact:
Michael Chynoweth
e-mail:  michael.w.chynoweth@intel.com
Phone:  (505) 893-1255
Comment 1 Michael Chynoweth 2004-04-27 14:18:18 EDT
Created attachment 99721 [details]
Test case for this bug.

This attachment comes with the readme on the bug and directions how to
reproduce.
Comment 2 Michael Chynoweth 2004-04-29 20:04:59 EDT
I tested this with the gcc-c++-2.96-128.7.2 compiler and it 
reproduces in the same manner.

Thanks,

Mike
Comment 3 Mike Simons 2004-04-30 13:21:56 EDT
Created attachment 99834 [details]
Makefile for testcase
Comment 4 Mike Simons 2004-04-30 13:22:53 EDT
Created attachment 99835 [details]
Test case
Comment 5 Mike Simons 2004-04-30 13:25:34 EDT
Created attachment 99836 [details]
Sample run

This shows a run of the program, and inspection of
the assembly to show the problem block.
Comment 6 Mike Simons 2004-04-30 13:26:46 EDT
Created attachment 99837 [details]
Description of the problem
Comment 7 Mike Simons 2004-04-30 13:32:51 EDT
The attachment Mike C, created is really a zip file with msdos text
format files inside... I've reattached the file pieces as plain unix
text files.

The test.cc file is about as small, touching the big "r1" data 
structure in almost any way makes the problem vanish.
Comment 8 RHEL Product and Program Management 2007-10-19 15:22:45 EDT
This bug is filed against RHEL2.1, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products.  Since
this bug does not meet that criteria, it is now being closed.

For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/

If you feel this bug is indeed mission critical, please contact your
support representative.  You may be asked to provide detailed
information on how this bug is affecting you.

Note You need to log in before you can comment on or make changes to this bug.