Re: [PATCH] Unbreak ia64 bootstrap (PR debug/45006)

[Richard Henderson <rth@redhat.com>]

On 07/20/2010 11:35 AM, Jakub Jelinek wrote:
> On Tue, Jul 20, 2010 at 10:55:31AM -0700, Richard Henderson wrote:
>> On 07/20/2010 09:36 AM, Jakub Jelinek wrote:
>>> My PR45003 fix apparently broke IA-64 bootstrap, because there
>>> FUNCTION_DECLs have DECL_MODE DImode, while TYPE_MODE of FUNCTION_TYPE
>>> is TImode.  Guess that's related to fn descriptors.
>>
>> How do the two modes get installed?  Because, really, these two should
>> match.  That this isn't the case doesn't make sense in the type model.
> 
> TYPE_MODE in layout_type:
>   SET_TYPE_MODE (type, mode_for_size (FUNCTION_BOUNDARY, MODE_INT, 0));

I think this usage of FUNCTION_BOUNDARY is wrong.  More below.

> and DECL_MODE in make_node_stat:
> 		  if (code == FUNCTION_DECL)
> 		    {
> 		      DECL_ALIGN (t) = FUNCTION_BOUNDARY;
> 		      DECL_MODE (t) = FUNCTION_MODE;
> 		    }
> 
>>> Either of the hunks should fix the ICE, though without the first hunk
>>> we just won't be able to emit useful debug info (as ADDR_EXPR <FUNCTION_DECL>
>>> will return NULL on ia64 then), and without the second hunk we risk we hit
>>> similar ICE later on.
>>
>> &function on ia64 may be resolved by ld.so.  I don't know if there's
>> anything particularly useful we could install here in the debug section.
> 
> With the patch it emits
> .LLST8:
>         data8.ua        .LVL18-.Ltext0  // Location list begin address (*.LLST8)
>         data8.ua        .LVL24-.Ltext0  // Location list end address (*.LLST8)
>         data2.ua        0xa     // Location expression size
>         data1   0x3     // DW_OP_addr
>         data8.ua        emutls_init#
>         data1   0x9f    // DW_OP_stack_value
>         data8.ua        0       // Location list terminator begin (*.LLST8)
>         data8.ua        0       // Location list terminator end (*.LLST8)
> 
> (for __func parameter of __gthread_once inline).  If you want, I can leave
> that first hunk of the patch out, so it will provide anything on ia64 again.
> 
> Or should we return NULL for ADDR_EXPR of FUNCTION_DECL in expand_debug_expr
> on fndesc targets right away?  Not sure if we have any macro for them
> though...

Hmm.  I tried to see what ppc64 would generate here, but couldn't seem to
prod the test case into stuffing the constant into the debug info.

I will say that this debug info quoted above is wrong, because the variable
does not contain a code address.

As for the MODEs, there's definitely some confusion here.

I see two possible solutions: (1) use a target macro/hook that indicates that
the target is using function descriptors, or (2) strictly disassociate the
FUNCTION_MODE and the FUNCTION_BOUNDARY, and if they don't match then infer
that a function descriptor must be in use.  The hook may be easier to manage,
and gives us a third piece of data against which we could detect inconsistencies.

With either solution we would need to audit all uses of FUNCTION_BOUNDARY and
DECL_ALIGN (function_decl) in generic code.

I'll also point out that rs6000 FUNCTION_MODE could be considered incorrect,
since it's hard-coded to SImode despite the Pmode function descriptor in use
for certain sub-targets.


r~