This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Unbreak ia64 bootstrap (PR debug/45006)
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
> 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
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.