This is the mail archive of the gcc-bugs@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]

[Bug target/13836] Illegal instruction calling function pointer


------- Additional Comments From sdowning at fame dot com  2004-01-26 21:47 -------
(In reply to comment #5)
> Subject: Re:  Illegal instruction calling function pointer 
> 
> 	I cannot duplicate this error and I don't really understand the
> explanation of GDB printing function descriptors.

I'm unfamiliar with the mechanics and purpose of the AIX TOC and was trying to
make sense of gdb output like this (example from my original program)...

(gdb) print Device[1]
$2 = {driver = @0x2023f130: 0x10132c, name = {0x200bda40 "VT125",
    0x200bda48 "VT125"}, got_windows = 1, clear_on_exit = 0}
(gdb) x/2x &Device[1]
0x200bd368 <Device+20>: 0x2023f130      0x200bda40
(gdb) x/x 0x2023f131
0x2023f131 <__dbargs+901>:      0x10132cf0
NOTE: I've added 1 to address in the struct!
(gdb) print VT125_manager
$4 = {FAMEINT (PACK_STR *)} 0x10132cf0 <VT125_manager(pack_str*)>

Device is a global array of structs containing a field(driver) that is a pointer
to function.  It was a surprise to me (as an AIX newbie) that the contents of
Device[1].field was not the address of VT125_manager, but rather the address of
a location containing the address of the function.  It appeared that the address
pointed to was in the TOC, but that was a stab on my part.


> 	TOC and function descriptors are separate things.  The TOC
> provides addressibility to global variables.
> 
> 	Function pointers on AIX point to function descriptors, which are
> a combination of function address and the TOC anchor for the module
> containing the function.  A function pointer, like any other pointer, can
> be stored in the TOC, but the function pointer does not point to a TOC
> entry. 

Clearly there's more to function pointers on AIX than I'm familiar with.

> 
> 	When I run the C++ application, compiled by gcc-3.3.2 on an AIX
> 5.1.0.0 system using the options listed in build_run.sh, I get the
> following output:
> 
> 200007f8
> 200007f8
> In driver
> In driver
> 
> If I examine the address 0x200007f8, I see
> 
> (gdb) x/2x 0x200007f8
> 0x200007f8 <__dbargs+532>:      0x100003f4      0x2000081c
> 
> which is the address of the function text and the address of the TOC
> base.

The problem could just be environmental.  I'm trying to explore system
maintenance level.

oslevel -r reports

5100-04

I see that maintenance level 5 is available and I will get that installed to see
if that helps.

> 
> 	You might try running the AIX command slibclean, as root, to make
> sure that you are not accidentally using an old shared library cached by
> the system.

I ran slibclean and reran build_run.sh.  I still get the illegal instruction.

> 	An unreferenced static array does not affect the function
> pointers.

For me, it does.  If I #define EXHIBIT_SYMPTOM 0, the problem goes away. 

> 	"pointer into the TOC" does not make any sense, so I do not know
> what you really are trying to say.  A function pointer is a single address
> of a function descriptor.  The compiler hides the two values (actually
> three), but the programmer does not need to manipulate two values.
> 
> 	Are you sure that the struct is not packed, breaking alignment
> rules for pointers?

I'm pretty sure it's not.  Output below demonstrates that the struct uses 0x14 =
20 bytes and is word-aligned.

(gdb) print &Device[0]
$3 = (DDSTRUCT *) 0x200bd354
(gdb) print &Device[1]
$4 = (DDSTRUCT *) 0x200bd368


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13836


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