From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6212 invoked by alias); 21 Feb 2002 21:16:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5997 invoked from network); 21 Feb 2002 21:16:10 -0000 Received: from unknown (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sources.redhat.com with SMTP; 21 Feb 2002 21:16:10 -0000 Received: from hiauly1.hia.nrc.ca (localhost [127.0.0.1]) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id g1LLG8FN023170; Thu, 21 Feb 2002 16:16:08 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) id g1LLG7ZB023169; Thu, 21 Feb 2002 16:16:07 -0500 (EST) Message-Id: <200202212116.g1LLG7ZB023169@hiauly1.hia.nrc.ca> Subject: Re: Help! DW function pointer encoding for PA To: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Thu, 21 Feb 2002 13:31:00 -0000 From: "John David Anglin" Cc: rth@redhat.com, gcc@gcc.gnu.org In-Reply-To: from "John David Anglin" at Feb 21, 2002 01:26:35 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg01207.txt.bz2 > I'll have to look more carefully at the ia64. I think I see what > ia64_expand_call is doing to handle the function descriptor vs FDE > issue: It appears that the PA has a serious problem in its handling of function descriptors. This small test program demonstrates the problem: int f (int (*func)(void)) { func(); } int main (void); int (*i)(void) = &main; int main() { f (i); f (main); } This is the assembly output showing how the plabels for the two calls in main are treated: addil LR'i-$global$,%r27 ldw RR'i-$global$(%r1),%r26 .CALL ARGW0=GR bl f,%r2 nop ldil LR'L$C0000,%r19 ldw RR'L$C0000(%r19),%r26 .CALL ARGW0=GR bl f,%r2 nop As can be seen, the call using plabel "i" is handled correctly. However, for the plabel L$C0000 used in the second call, we are in fact loading the address of the function from the descriptor rather than the address of the descriptor. Thus, indirect calls where the pic register changes value won't work. I don't know how this went unnoticed for so long. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605)