* [parisc-linux] Re: c++ problem
[not found] <Pine.LNX.4.21.0103210901030.25567-100000@front.linuxcare.com.au>
@ 2001-03-20 23:51 ` Alan Modra
2001-03-21 0:37 ` Alan Modra
0 siblings, 1 reply; 4+ messages in thread
From: Alan Modra @ 2001-03-20 23:51 UTC (permalink / raw
To: Matt Taggart
Cc: randolph, Paul J.Y. Lahaie, Richard Hirst, Jane Vinet,
parisc-linux
On Wed, 21 Mar 2001, Alan Modra wrote:
> What is interesting from the above is that if my std::basic_ios::widen
> function happened to need a plt call stub, then my `hello' prog would
> crash too for the same reason.
This is probably relevant to the perl problem too, hence the extra cc's.
Take a look at the following gdb dump. I've added a few comments `#...'
alan@tea:/scsi/tmp$ gdb test.tagg2
GNU gdb 5.0
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "hppa-linux"...(no debugging symbols found)...
(gdb) set env LD_LIBRARY_PATH=.
(gdb) b *0x1724 # The plt call stub where we crash
Breakpoint 1 at 0x1724
(gdb) b _init
Breakpoint 2 at 0x16c4
(gdb) b _start
Breakpoint 3 at 0x17b4
(gdb) r
Starting program: /scsi/tmp/test.tagg2
Breakpoint 1, 0x00001724 in _end_init ()
(gdb) set var $dp=0x2d90 # cheat. set up dp = $global$
(gdb) c
Continuing.
Breakpoint 1, 0x00001724 in _end_init ()
(gdb) p/x $dp
$1 = 0x2d90
(gdb) c
Continuing.
Breakpoint 1, 0x00001724 in _end_init ()
(gdb) c
Continuing.
Breakpoint 1, 0x00001724 in _end_init ()
(gdb) c
Continuing.
Breakpoint 3, 0x000017b4 in _start ()
(gdb) c
Continuing.
Breakpoint 2, 0x000016c4 in _init ()
(gdb) c
Continuing.
Breakpoint 1, 0x00001724 in _end_init ()
(gdb) disable 1
(gdb) c
Continuing.
Hello
Program exited normally.
The problem is that dp is set up in _start. Any plt call stubs __in the
main application__ called before _start runs will die horribly. It's OK
to call plt call stubs in a shared lib as they use r19.
I propose we set up dp in the dynamic linker to avoid this problem, as
it's quite legal to have a mix of static and dynamic libraries, each
needing to run constructors.
Alan
--
Linuxcare
^ permalink raw reply [flat|nested] 4+ messages in thread
* [parisc-linux] Re: c++ problem
2001-03-20 23:51 ` [parisc-linux] Re: c++ problem Alan Modra
@ 2001-03-21 0:37 ` Alan Modra
2001-03-21 1:33 ` Alan Modra
0 siblings, 1 reply; 4+ messages in thread
From: Alan Modra @ 2001-03-21 0:37 UTC (permalink / raw
To: Matt Taggart
Cc: randolph, Paul J.Y. Lahaie, Richard Hirst, Jane Vinet,
parisc-linux
On Wed, 21 Mar 2001, Alan Modra wrote:
> I propose we set up dp in the dynamic linker to avoid this problem, as
> it's quite legal to have a mix of static and dynamic libraries, each
> needing to run constructors.
I think this is all we need. Compiling it all to test it out...
--- glibc/sysdeps/hppa/dl-machine.h~ Mon Feb 19 14:05:42 2001
+++ glibc/sysdeps/hppa/dl-machine.h Wed Mar 21 10:45:50 2001
@@ -338,6 +338,10 @@
/* Save the entry point in %r3. */
copy %ret0,%r3
+ /* Set up dp for any static lib constructors that may be called. */
+ addil LT'$global$,%r19
+ ldw RT'$global$(%r1),%dp
+
/* Remember the lowest stack address. */
addil LT'__libc_stack_end,%r19
ldw RT'__libc_stack_end(%r1),%r20
Alan
--
Linuxcare
^ permalink raw reply [flat|nested] 4+ messages in thread
* [parisc-linux] Re: c++ problem
2001-03-21 0:37 ` Alan Modra
@ 2001-03-21 1:33 ` Alan Modra
2001-03-21 4:53 ` Alan Modra
0 siblings, 1 reply; 4+ messages in thread
From: Alan Modra @ 2001-03-21 1:33 UTC (permalink / raw
To: Matt Taggart
Cc: randolph, Paul J.Y. Lahaie, Richard Hirst, Jane Vinet,
parisc-linux
On Wed, 21 Mar 2001, Alan Modra wrote:
> On Wed, 21 Mar 2001, Alan Modra wrote:
>
> > I propose we set up dp in the dynamic linker to avoid this problem, as
> > it's quite legal to have a mix of static and dynamic libraries, each
> > needing to run constructors.
>
> I think this is all we need. Compiling it all to test it out...
>
> --- glibc/sysdeps/hppa/dl-machine.h~ Mon Feb 19 14:05:42 2001
> +++ glibc/sysdeps/hppa/dl-machine.h Wed Mar 21 10:45:50 2001
> @@ -338,6 +338,10 @@
> /* Save the entry point in %r3. */
> copy %ret0,%r3
>
> + /* Set up dp for any static lib constructors that may be called. */
> + addil LT'$global$,%r19
> + ldw RT'$global$(%r1),%dp
> +
> /* Remember the lowest stack address. */
> addil LT'__libc_stack_end,%r19
> ldw RT'__libc_stack_end(%r1),%r20
Unfortunately, this fails because we pick up the value of $global$ in
ld.so. Has anybody got a good idea on how to solve this? One possibility
that occurs to me is that the dynamic linker could pull out DT_PLTGOT for
the application, but I'm not sure how to do that.
Alan
--
Linuxcare
^ permalink raw reply [flat|nested] 4+ messages in thread
* [parisc-linux] Re: c++ problem
2001-03-21 1:33 ` Alan Modra
@ 2001-03-21 4:53 ` Alan Modra
0 siblings, 0 replies; 4+ messages in thread
From: Alan Modra @ 2001-03-21 4:53 UTC (permalink / raw
To: Matt Taggart
Cc: randolph, Paul J.Y. Lahaie, Richard Hirst, Jane Vinet,
parisc-linux
A cure!
* sysdeps/hppa/dl-machine.h (RTLD_START): Set up dp with DT_PLTGOT
value from application so that constructors in non-PIC libs work.
Alan Modra
--
Linuxcare
Index: sysdeps/hppa/dl-machine.h
===================================================================
RCS file: /home/cvs/parisc/glibc/sysdeps/hppa/dl-machine.h,v
retrieving revision 1.39
diff -u -p -r1.39 dl-machine.h
--- dl-machine.h 2000/12/13 20:12:42 1.39
+++ dl-machine.h 2001/03/21 04:36:15
@@ -255,7 +255,17 @@ elf_machine_runtime_setup (struct link_m
The C function `_dl_start' is the real entry point;
its return value is the user program's entry point. */
-#define RTLD_START asm ("\
+#define RTLD_START \
+/* Set up dp for any static lib constructors that may be called. */ \
+static struct link_map * set_dp (struct link_map *map) \
+{ \
+ register Elf32_Addr dp asm ("%r27"); \
+ dp = D_PTR (map, l_info[DT_PLTGOT]); \
+ asm volatile ("" : : "r" (dp)); \
+ return map; \
+} \
+ \
+asm ("\
.text
.globl _start
.type _start,@function
@@ -331,7 +341,6 @@ _start:
bl _dl_start,%rp
ldo -4(%r24),%r26
- /* FALLTHRU */
.globl _dl_start_user
.type _dl_start_user,@function
_dl_start_user:
@@ -359,10 +368,14 @@ _dl_start_user:
stw %r24,-44(%sp)
.Lnofix:
- /* Call _dl_init(_dl_loaded, argc, argv, envp). */
addil LT'_dl_loaded,%r19
ldw RT'_dl_loaded(%r1),%r26
+ bl set_dp, %r2
ldw 0(%r26),%r26
+
+ /* Call _dl_init(_dl_loaded, argc, argv, envp). */
+ copy %r28,%r26
+
/* envp = argv + argc + 1 */
sh2add %r25,%r24,%r23
bl _dl_init,%r2
@@ -389,7 +402,9 @@ __dl_fini_plabel:
stw %r19,4(%r23)
ldw 4(%r3),%r19 /* load the object's gp */
bv %r0(%r2)
- depi 2,31,2,%r23 /* delay slot */");
+ depi 2,31,2,%r23 /* delay slot */
+");
+
/* This code gets called via the .plt stub, and is used in
dl-runtime.c to call the `fixup' function and then redirect to the
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-03-21 4:55 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <Pine.LNX.4.21.0103210901030.25567-100000@front.linuxcare.com.au>
2001-03-20 23:51 ` [parisc-linux] Re: c++ problem Alan Modra
2001-03-21 0:37 ` Alan Modra
2001-03-21 1:33 ` Alan Modra
2001-03-21 4:53 ` Alan Modra
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.