* HPUX function address.
@ 2003-10-14 21:36 Daniel Grunblatt
2003-10-14 22:22 ` law
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Grunblatt @ 2003-10-14 21:36 UTC (permalink / raw)
To: gcc
Hi,
I've found the following problem:
spe170> cc -v
Reading specs from /usr/lib/gcc-lib/hppa-linux/3.0.4/specs
Configured with: ../src/configure -v --enable-languages=c,c++,f77,proto,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 hppa-linux
Thread model: posix
gcc version 3.0.4
spe170> cc -g -o func func.c
spe170> gdb func
GNU gdb 2002-04-01-cvs
Copyright 2002 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"...
(gdb) l
3 int
4 func()
5 {
6 return;
7 }
8
9 int
10 main()
11 {
12 printf("0x%x\n", (long)func);
(gdb)
13 }
(gdb) b 12
Breakpoint 1 at 0x10524: file func.c, line 12.
(gdb) r
Starting program: /house/grunblat/hp-ux/c/func
Breakpoint 1, main () at func.c:12
12 printf("0x%x\n", (long)func);
(gdb) p func
$1 = {int ()} 0x104fc <func>
(gdb) n
0x207ee
Program exited with code 010.
(gdb)
I think it should print 0x104fc, right?
Is there a compiler switch I'm missing?
Should I just try another compiler version?
Thanks in advance.
Daniel Grunblatt.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HPUX function address.
2003-10-14 21:36 HPUX function address Daniel Grunblatt
@ 2003-10-14 22:22 ` law
2003-10-15 22:49 ` Daniel Grunblatt
0 siblings, 1 reply; 6+ messages in thread
From: law @ 2003-10-14 22:22 UTC (permalink / raw)
To: Daniel Grunblatt; +Cc: gcc
In message <200310141805.05520.daniel@grunblatt.com.ar>, Daniel Grunblatt write
s:
>Hi,
> I've found the following problem:
>
>spe170> cc -v
>Reading specs from /usr/lib/gcc-lib/hppa-linux/3.0.4/specs
>Configured with: ../src/configure -v --enable-languages=c,c++,f77,proto,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 hppa-linux
>Thread model: posix
>gcc version 3.0.4
>spe170> cc -g -o func func.c
>spe170> gdb func
>GNU gdb 2002-04-01-cvs
>Copyright 2002 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"...
>(gdb) l
>3 int
>4 func()
>5 {
>6 return;
>7 }
>8
>9 int
>10 main()
>11 {
>12 printf("0x%x\n", (long)func);
>(gdb)
>13 }
>(gdb) b 12
>Breakpoint 1 at 0x10524: file func.c, line 12.
>(gdb) r
>Starting program: /house/grunblat/hp-ux/c/func
>
>Breakpoint 1, main () at func.c:12
>12 printf("0x%x\n", (long)func);
>(gdb) p func
>$1 = {int ()} 0x104fc <func>
>(gdb) n
>0x207ee
>
>Program exited with code 010.
>(gdb)
>
>I think it should print 0x104fc, right?
Nope. 0x207ee is the address of the procedure descriptor.
0x207ec will contain the function's actual address
0x207f0 will contain the function's DP value
When you dereference the function you get a call to $$dyncall which
extracts the DP value from the desciptor and stuffs it into $r27, then
extracts the function's actual address and transfers control to that
actual address.
GDB does not construct procedure descriptors when you try to print a
function's address.
FWIW, similar schemes are found on IA-64 as well.
>Is there a compiler switch I'm missing?
>Should I just try another compiler version?
Nope. This is how things are expected to work on PAs.
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HPUX function address.
2003-10-14 22:22 ` law
@ 2003-10-15 22:49 ` Daniel Grunblatt
2003-10-15 23:47 ` law
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Grunblatt @ 2003-10-15 22:49 UTC (permalink / raw)
To: law; +Cc: gcc
On Tuesday 14 October 2003 18:31, law@redhat.com wrote:
>
> Nope. 0x207ee is the address of the procedure descriptor.
>
> 0x207ec will contain the function's actual address
> 0x207f0 will contain the function's DP value
(gdb) b 12
Breakpoint 1 at 0x10524: file func.c, line 12.
(gdb) r
Starting program: /house/grunblat/hp-ux/c/func
Breakpoint 1, main () at func.c:12
12 printf("0x%x\n", (long)func);
(gdb) p func
$1 = {int ()} 0x104fc <func>
(gdb) x/8wx 0x207ec
0x207ec <__DTOR_END__+44>: 0x00020818 0x0000003c 0x40139e88
0x40174af0
0x207fc <__DTOR_END__+60>: 0x40049c54 0x40174af0 0x000105e8
0x000206ec
(gdb) x/8wx 0x00020818
0x20818 <__DTOR_END__+88>: 0xea9f1fdd 0xd6801c1e 0x4000c7d8
0x40026754
0x20828 <_GLOBAL_OFFSET_TABLE_>: 0x00020704 0x40027d08
0x00000000 0x00000000
(gdb)
0x207ec doesn't contain it, I was wrong to say HP-UX, it's a linux running on
hppa, is that the problem? or can I just call 0x00020818 and expect 'func'
to be reached?
>
> When you dereference the function you get a call to $$dyncall which
> extracts the DP value from the desciptor and stuffs it into $r27, then
> extracts the function's actual address and transfers control to that
> actual address.
>
> GDB does not construct procedure descriptors when you try to print a
> function's address.
>
> FWIW, similar schemes are found on IA-64 as well.
>
> >Is there a compiler switch I'm missing?
> >Should I just try another compiler version?
>
> Nope. This is how things are expected to work on PAs.
>
> jeff
Thanks for your reply,
Daniel Grunblatt.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HPUX function address.
2003-10-15 22:49 ` Daniel Grunblatt
@ 2003-10-15 23:47 ` law
0 siblings, 0 replies; 6+ messages in thread
From: law @ 2003-10-15 23:47 UTC (permalink / raw)
To: Daniel Grunblatt; +Cc: gcc
In message <200310151855.54918.daniel@grunblatt.com.ar>, Daniel Grunblatt write
s:
>On Tuesday 14 October 2003 18:31, law@redhat.com wrote:
>>
>> Nope. 0x207ee is the address of the procedure descriptor.
>>
>> 0x207ec will contain the function's actual address
>> 0x207f0 will contain the function's DP value
>
>(gdb) b 12
>Breakpoint 1 at 0x10524: file func.c, line 12.
>(gdb) r
>Starting program: /house/grunblat/hp-ux/c/func
>
>Breakpoint 1, main () at func.c:12
>12 printf("0x%x\n", (long)func);
>(gdb) p func
>$1 = {int ()} 0x104fc <func>
>(gdb) x/8wx 0x207ec
>0x207ec <__DTOR_END__+44>: 0x00020818 0x0000003c 0x40139e88
>
>0x40174af0
>0x207fc <__DTOR_END__+60>: 0x40049c54 0x40174af0 0x000105e8
>
>0x000206ec
>(gdb) x/8wx 0x00020818
>0x20818 <__DTOR_END__+88>: 0xea9f1fdd 0xd6801c1e 0x4000c7d8
>
>0x40026754
>0x20828 <_GLOBAL_OFFSET_TABLE_>: 0x00020704 0x40027d08
>0x00000000 0x00000000
>(gdb)
>
>0x207ec doesn't contain it, I was wrong to say HP-UX, it's a linux running on
>
>hppa, is that the problem? or can I just call 0x00020818 and expect 'func'
>to be reached?
Linux has a different way of representing function addresses than HP-UX.
Unfortunately, I'm not that familiar with the Linux model, so I don't
know precisely how it works. John or Alan might be able to help.
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HPUX function address.
@ 2003-10-15 23:20 John David Anglin
0 siblings, 0 replies; 6+ messages in thread
From: John David Anglin @ 2003-10-15 23:20 UTC (permalink / raw)
To: gcc; +Cc: daniel
> 0x207ec doesn't contain it, I was wrong to say HP-UX, it's a linux running on
> hppa, is that the problem? or can I just call 0x00020818 and expect 'func'
> to be reached?
The situations are similar but there are slight implementation differences
between linux and hpux. The default on linux is to use lazy linking.
Initially, all function descriptors point to a small bit of code in the
global offset table which jumps to a routine in the dynamic loader to
resolve the address of the function and build the function descriptor.
After the first call to a function, the function descriptor will be setup
as indicated by Jeff.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HPUX function address.
@ 2003-10-14 23:25 John David Anglin
0 siblings, 0 replies; 6+ messages in thread
From: John David Anglin @ 2003-10-14 23:25 UTC (permalink / raw)
To: gcc; +Cc: daniel
> I think it should print 0x104fc, right?
Wrong. A function pointer may point to a function descriptor. You
have to test the plabel bit to determine if a function pointer points
to a function descriptor or not. Get a copy of the HP-UX Runtime
Architecture document
http://h21007.www2.hp.com/dspp/tech/tech_TechTypeListingPage_IDX/1,1704,10403,00.html
for more information.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-10-15 22:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-14 21:36 HPUX function address Daniel Grunblatt
2003-10-14 22:22 ` law
2003-10-15 22:49 ` Daniel Grunblatt
2003-10-15 23:47 ` law
2003-10-14 23:25 John David Anglin
2003-10-15 23:20 John David Anglin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).