This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: HPUX function address.


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






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]