[Bug c++/13836] New: Illegal instruction calling function pointer

[Bug c++/13836] New: Illegal instruction calling function pointer

[sdowning at fame dot com]

A coredump resulting from an illegal instruction occurs when calling a function
pointer corresponding to a function in a separate module that contains a static,
statically initialized (with non-zero values) array of characters.

The module driver.cc contains a static array of characters.  The macro
EXHIBIT_SYMPTOM can be set to 0 to cause the symptom to go away.

The symptom can also be suppressed by
1) Initializing the array to zero values
2) Moving the array before the driver function
3) Declaring the array global rather than static

The symptom in the test case only occurs in the debug build (see build_run.sh)
but in the larger program that precipitated the test case, the symptom occurs in
 non-debug builds as well.  I have been able to workaround this issue by making
sure any functions pointed to are defined at the end of the module.

-- 
           Summary: Illegal instruction calling function pointer
           Product: gcc
           Version: 3.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sdowning at fame dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-ibm-aix5.1.0.0
  GCC host triplet: powerpc-ibm-aix5.1.0.0
GCC target triplet: powerpc-ibm-aix5.1.0.0


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

[Bug c++/13836] Illegal instruction calling function pointer

[sdowning at fame dot com]

------- Additional Comments From sdowning at fame dot com  2004-01-23 18:45 -------
Created an attachment (id=5563)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=5563&action=view)
2 source files, 2 intermediate files, test script and my test output


-- 


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

[Bug c++/13836] Illegal instruction calling function pointer

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code


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

[Bug target/13836] Illegal instruction calling function pointer

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-24 00:14 -------
I cannot see anything wrong with the asm at all.
David could you look into this.  I am wondering if there is not a hardware problem.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at gcc dot gnu dot org
          Component|c++                         |target


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

[Bug target/13836] Illegal instruction calling function pointer

[sdowning at fame dot com]

------- Additional Comments From sdowning at fame dot com  2004-01-26 15:01 -------
(In reply to comment #2)
Background:
As I understand it, on RS/6000, pointers to functions point indirectly to the
function in question.  They point to a TOC entry which in turn points to the
function in question.  In gdb, function pointers are displayed like
"@0x12345678: 0xfedcba98", where 0x12345678 is the address in the TOC and
0xfedcba98 is the address of the function.

Foreground:
In my original code, I have an array of structs wherein one of the fields is a
pointer to a function.  These are statically initialized.  My original symptom
is that at load time, these function pointers are invalid in the following way:
The pointers into the TOC are 1-3 bytes too small.  

Example: The TOC contains:

TOC Address    Contents
0x12345674:    00 00 00 00 fe dc ba 98 76 54 32 10 

If the appropriate TOC address for my function pointer is 0x12345678, the value
might end up as 0x123456 ... 77, 76, or 75.  In gdb it would be displayed as
@0x12345677: 0xfedcba, @0x12345676: 0xfedc, or @0x12345675: 0xfe.

When I examined my array in gdb, all the function pointers that were invalid
(not all were) had the correct function pointer in the TOC 1, 2 or 3 bytes after
the function pointer's address.

I thought this was an AIX linker problem, and perhaps it is, but I haven't found
any ld patches that seem to address the symptom.


-- 


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

[Bug target/13836] Illegal instruction calling function pointer

[dje at watson dot ibm dot com]

------- Additional Comments From dje at watson dot ibm dot com  2004-01-26 18:31 -------
Subject: Re:  Illegal instruction calling function pointer 



-- 


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

[Bug target/13836] Illegal instruction calling function pointer

[dje at watson dot ibm dot com]

------- Additional Comments From dje at watson dot ibm dot com  2004-01-26 18:57 -------
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.

	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. 

	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.

	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.

	An unreferenced static array does not affect the function
pointers.

	"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?

David


-- 


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

[Bug target/13836] Illegal instruction calling function pointer

[sdowning at fame dot com]

------- 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

[Bug target/13836] Illegal instruction calling function pointer

[dje at watson dot ibm dot com]

------- Additional Comments From dje at watson dot ibm dot com  2004-01-26 22:07 -------
Subject: Re:  Illegal instruction calling function pointer 

	Neither the attachments nor the text in the bug report contain a
definition of the Device array of structs.

$ oslevel -r 
5100-04

	Please make sure that you are using the native AIX assembler and
linker, not the AIX Toolchain for Linux.  The output in the attachment
shows:

 /usr/local/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.3.2/../../../../powerpc-ibm-aix5.1.0.0/bin/as -u -mcom -o main.o main.s

My output shows:

 as -u -mcom -o /tmp//ccYIvXpa.o /tmp//ccZ1r9Zl.s

I assume that you have GNU as and GNU ld installed and are using them.
The installation instructions state that native as and ld are required for
AIX 5L.

David



-- 


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

[Bug target/13836] Illegal instruction calling function pointer

[sdowning at fame dot com]

------- Additional Comments From sdowning at fame dot com  2004-01-27 13:27 -------
(In reply to comment #7) 
> Subject: Re:  Illegal instruction calling function pointer  
>  
>         Neither the attachments nor the text in the bug report contain a 
> definition of the Device array of structs. 
 
When you said to check that the struct wasn't packed, I assumed you were 
referring to my original program, not the sample code (which doesn't contain 
any structs) 
 
>         Please make sure that you are using the native AIX assembler and 
> linker, not the AIX Toolchain for Linux.   
 
Looks like this is probably the issue.  I didn't build gcc from scratch, I 
downloaded from UCLA's Public Domain Software Library.  I'd be surprised if 
they built with the GNU as, so I have a config problem. 
 
Just mv'd the as and ld that gcc was using to gnu-as and gnu-ld, reran my test 
case and the symptom goes away. 
 
Thanks for the hand holding. 
 

-- 


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

[Bug target/13836] Illegal instruction calling function pointer

[dje at gcc dot gnu dot org]

------- Additional Comments From dje at gcc dot gnu dot org  2004-01-27 15:06 -------
incorrect assembler and linker used

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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