RE: [parisc-linux] Program counter from sigcontext, constructors

RE: [parisc-linux] Program counter from sigcontext, constructors

[Boehm, Hans]

Thanks.

It turns out the constructor issue does have a simple test case.  I assume the issues is with -fPIC code in a main program constructor?  With luck, this may only matter for my test case.  For any real use, this would be in a dynamic library.

Hans

spe170> cat constr.c
#include <stdio.h>

int x = 42;

int y;

void my_start(void) __attribute__ ((constructor));

main()
{
  printf("x, y = %d, %d \n", x, y);
  return 0;
}


void my_start(void)
{
  y = x;
}
spe170> cc -fPIC -g constr.c
spe170> ./a.out
Segmentation fault
spe170> cc -g constr.c
spe170> ./a.out
x, y = 42, 42
spe170>

> -----Original Message-----
> From: John David Anglin [mailto:dave@hiauly1.hia.nrc.ca]
> Sent: Friday, April 25, 2003 12:56 PM
> To: hans_boehm@hp.com
> Cc: carlos@baldric.uwo.ca; parisc-linux@lists.parisc-linux.org;
> hans_boehm@hp.com
> Subject: Re: [parisc-linux] Program counter from sigcontext,
> constructurs
> 
> 
> > > > 2) If I mark a C function as a constructor function, and 
> > > compile it with -fPIC, it seems to run before globals are 
> > > properly accessible.  The retrieval of the address of a 
> > > global through the global offset table seems to return a bad 
> > > address and the access faults.  Are there known issues in 
> > > this area?  (The offending function actually ends up in the 
> > > main program, if that matters.)
> 
> I'm not aware of any.  All the libstdc++ test pass and this involves
> running constructors in a shared library, so it would seem the PIC
> register and got table must be setup.  Function pointer 
> canonicalization
> involves accessing the got table in some situations.  This can happen
> in crtstuff.c which runs constructors.  Do you have a testcase?
> 
> It might be a linker issue.  There are some subtle issues with calling
> PIC code that's not in a shared library.
> 
> Dave
> -- 
> J. David Anglin                                  
> dave.anglin@nrc-cnrc.gc.ca
> National Research Council of Canada              (613) 
> 990-0752 (FAX: 952-6602)
> 

Re: [parisc-linux] Program counter from sigcontext, constructors

[John David Anglin]

> spe170> cc -fPIC -g constr.c
> spe170> ./a.out
> Segmentation fault

I'm unable to duplicate this on gsyprf11.  I tried several gcc versions.
I'm using glibc 2.3.1-15.  ld is version 2.13.90 20030210.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Program counter from sigcontext, constructors

[Carlos O'Donell]

> > spe170> cc -fPIC -g constr.c
> > spe170> ./a.out
> > Segmentation fault
> 
> I'm unable to duplicate this on gsyprf11.  I tried several gcc versions.
> I'm using glibc 2.3.1-15.  ld is version 2.13.90 20030210.
> 

Which versions did you try? :)

bash-2.05b$ gcc-3.0 -fPIC -g test-fpic.c; ./a.out
Segmentation fault

GNU ld version 2.13.90.0.18 20030121 Debian GNU/Linux

Reading specs from /usr/lib/gcc-lib/hppa-linux/3.0.4/specs
Configured with: ../src/configure -v --enable-languages=c,c++,f77,objc
--prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared
--with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long
--enable-nls --without-included-gettext --disable-checking
--enable-threads=posix --with-cpp-install-dir=bin --enable-objc-gc
hppa-linux
Thread model: posix
gcc version 3.0.4

Crashes under 3.0.4, looks like the possible PIC register bug we saw
with the double printf. I recommend you move to a newer gcc if possible.
I spent a few minutes looking at assembler output and %r19 looks to low
to be valid...

c.

Re: [parisc-linux] Program counter from sigcontext, constructors

[John David Anglin]

> Which versions did you try? :)
> 
> bash-2.05b$ gcc-3.0 -fPIC -g test-fpic.c; ./a.out
> Segmentation fault

gcc version 3.2.3 20030316 (Debian prerelease)
gcc version 3.3 20030419 (prerelease)
gcc version 3.4 20030115 (experimental)

> Crashes under 3.0.4, looks like the possible PIC register bug we saw
> with the double printf. I recommend you move to a newer gcc if possible.
> I spent a few minutes looking at assembler output and %r19 looks to low
> to be valid...

This is a bug in 3.0.4.  If you look at the assembler output for the
testcase, you will see the following:

	.section	.ctors,"aw"
	.long	my_start

This is incorrect.  The code should be:

	.section	.ctors,"aw",@progbits
	.align	4
	.word	P%my_start

Using a plabel constructor causes $$dyncall to correctly load the
pic register for the call to my_start.  This is necessary because
the startup file crtbegin.o is not compiled as pic code and the
code in __do_global_ctors_aux clobbers the pic register.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Program counter from sigcontext, constructors

[Carlos O'Donell]

> This is a bug in 3.0.4.  If you look at the assembler output for the
> testcase, you will see the following:
> 
> 	.section	.ctors,"aw"
> 	.long	my_start
> 
> This is incorrect.  The code should be:
> 
> 	.section	.ctors,"aw",@progbits
> 	.align	4
> 	.word	P%my_start
> 
> Using a plabel constructor causes $$dyncall to correctly load the
> pic register for the call to my_start.  This is necessary because
> the startup file crtbegin.o is not compiled as pic code and the
> code in __do_global_ctors_aux clobbers the pic register.

Good catch. I hadn't bothered looking at the .S!
Again the recommendation is going to be "Use a newer gcc" :)

c.

Re: [parisc-linux] Program counter from sigcontext, constructors

[John David Anglin]

> Good catch. I hadn't bothered looking at the .S!
> Again the recommendation is going to be "Use a newer gcc" :)

I should have mentioned that the problem is fixed in all the gcc versions
that I originally tried.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)