debug_hooks->end_prologue problem

debug_hooks->end_prologue problem

[Douglas B Rupp]

The HP debugger on IA64 VMS defines a new Dwarf2 attribute that computes the
offset of the end of the prologue from the beginning of the function. To
implement this an end prologue label must be emitted and some related info
saved in dwarf2out.c. 

However I've noted that calling debug_hooks->end_prologue as it is now
results in a label at the beginning of the prologue, not the end. I've
attached the obvious fix below, but I fear it might mess up sdbout.c. Should
I create a new hook or investigate the impact on sdbout and try to fix it?

--Douglas Rupp
AdaCore
 

*** gcc/final.c     2006-01-26 00:39:12.000000000 -0800
--- gcc/final.c  2006-01-26 00:12:21.000000000 -0800
*************** final_scan_insn (rtx insn, FILE *file, i
*** 1704,1709 ****
--- 1704,1710 ----
        case NOTE_INSN_PROLOGUE_END:
          (*targetm.asm_out.function_end_prologue) (file);
          profile_after_prologue (file);
+         (*debug_hooks->end_prologue) (last_linenum, last_filename);
  
          if ((*seen & (SEEN_EMITTED | SEEN_NOTE)) == SEEN_NOTE)
            {
*************** final_scan_insn (rtx insn, FILE *file, i
*** 1716,1727 ****
          break;
  
        case NOTE_INSN_EPILOGUE_BEG:
          (*targetm.asm_out.function_begin_epilogue) (file);
          break;
  
        case NOTE_INSN_FUNCTION_BEG:
          app_disable ();
-         (*debug_hooks->end_prologue) (last_linenum, last_filename);
  
          if ((*seen & (SEEN_EMITTED | SEEN_NOTE)) == SEEN_NOTE)
            {

Re: debug_hooks->end_prologue problem

[Jim Wilson]

Douglas B Rupp wrote:
> The HP debugger on IA64 VMS defines a new Dwarf2 attribute that computes the
> offset of the end of the prologue from the beginning of the function. To
> implement this an end prologue label must be emitted and some related info
> saved in dwarf2out.c. 
> 
> However I've noted that calling debug_hooks->end_prologue as it is now
> results in a label at the beginning of the prologue, not the end. I've
> attached the obvious fix below, but I fear it might mess up sdbout.c. Should
> I create a new hook or investigate the impact on sdbout and try to fix it?

Belatedly looking at this, you seem to be confused over the purpose of 
the NOTE_INSN_FUNCTION_BEG note.  It does not mark the beginning of the 
function.  That is the first RTL insn.  Instead, it marks the beginning 
of the function body.

If you compile without optimization, then this is the same as the 
prologue end.  If you compile with optimization, then the function body 
and the prologue overlap.  Now the question is, do you really want to 
mark the beginning of the function body (which may be before the 
prologue end), or the end of the prologue (which may be after the 
function body beginning).  Either way, it is likely that someone may not 
be happy.  However, in general, the former (function body beginning) is 
more useful to end users, as otherwise they won't be able to debug all 
of the code in the function body.  So the current code in final.c looks 
correct.

Othogonal to this, there is the problem of what to do with these notes 
when instruction scheduling is enabled.  It looks like the current code 
just always moves notes to the beginning of the basic block containing 
them.  That means effectively that the function beginning is always 
before the prologue.  However, the prologue end note also ends up before 
the prologue in the same place.  So using that one doesn't help.  The 
only solution is a more general one.  In the scheduler, before 
scheduling, you need to mark all instructions that originally came from 
the prologue.  After scheduling, you go back through, find the first 
non-prologue instruction, and insert the NOTE_INSN_FUNCTION_BEG note 
before it.  You find the last prologue instruction, and insert the 
NOTE_INSN_PROLOGUE_END note after it.  You would also have to do the 
same (reversed) for the epilogue.  It isn't clear if this extra work is 
worthwhile.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: debug_hooks->end_prologue problem

[Eric Botcazou]

> If you compile without optimization, then this is the same as the
> prologue end.  If you compile with optimization, then the function body
> and the prologue overlap.  Now the question is, do you really want to
> mark the beginning of the function body (which may be before the
> prologue end), or the end of the prologue (which may be after the
> function body beginning).  Either way, it is likely that someone may not
> be happy.  However, in general, the former (function body beginning) is
> more useful to end users, as otherwise they won't be able to debug all
> of the code in the function body.  So the current code in final.c looks
> correct.

Yes, the code in final.c is OK.  However, there is a bug pertaining to the 
placement of the NOTE_INSN_FUNCTION_BEG note for parameterless functions.

void foo(void)
{
  int i = 0;
}

In .flow2 at -O0:

(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)

;; Start of basic block 3, registers live: 6 [bp] 7 [sp] 16 [argp] 20 [frame]
(note 6 3 19 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn/f 19 6 20 3 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
        (reg/f:DI 6 bp)) -1 (nil)
    (nil))

(insn/f 20 19 21 3 (set (reg/f:DI 6 bp)
        (reg/f:DI 7 sp)) -1 (nil)
    (nil))

(note 21 20 8 3 NOTE_INSN_PROLOGUE_END)


void bar(int par)
{
 int i = 0;
}

(insn/f 20 6 21 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
        (reg/f:DI 6 bp)) -1 (nil)
    (nil))

(insn/f 21 20 22 2 (set (reg/f:DI 6 bp)
        (reg/f:DI 7 sp)) -1 (nil)
    (nil))

(note 22 21 3 2 NOTE_INSN_PROLOGUE_END)

(insn 3 22 4 2 (set (mem/c/i:SI (plus:DI (reg/f:DI 6 bp)
                (const_int -20 [0xffffffffffffffec])) [0 par+0 S4 A32])
        (reg:SI 5 di [ par ])) 40 {*movsi_1} (nil)
    (nil))

(note 4 3 9 2 NOTE_INSN_FUNCTION_BEG)


function.c:thread_prologue_and_epilogue_insns has code to fix up the order of 
NOTE_INSN_FUNCTION_BEG and NOTE_INSN_FUNCTION_END notes for the epilogue, but 
not for the prologue.  We've found out in the meantime that it was the root 
cause of Doug's problem and fixed it locally.

> Othogonal to this, there is the problem of what to do with these notes
> when instruction scheduling is enabled.
> [...]
> It isn't clear if this extra work is worthwhile.

Yes, the interaction with scheduling is another, more difficult problem.  And 
I don't think we really care about it for Doug's work.

Thanks for your feedback.

-- 
Eric Botcazou