* Multiple calls to case NOTE_INSN_EPILOGUE_BEG for same function?
@ 2009-07-12 19:30 Douglas B Rupp
2009-07-15 17:57 ` Richard Henderson
0 siblings, 1 reply; 6+ messages in thread
From: Douglas B Rupp @ 2009-07-12 19:30 UTC (permalink / raw)
To: gcc; +Cc: rth
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]
I've been working on bringing the VMS patches up to date. The VMS
Debugger requires a label at end prologue and begin_epilogue, and the
fact that final_scan_insn makes multiple calls to NOTE_INSN_EPILOGUE_BEG
for the same function makes this awkward. I suppose it could be case
that there are multiple epilogues in a function, but the generated
assembly code doesn't seem to indicate this. Below is an excerpt from a
gdb session, and attached is a file derived from argv.c.
Can someone please explain why this happens and if a bug, please advise
on how to fix?
--Douglas Rupp
AdaCore
Breakpoint 3, emit_note (kind=NOTE_INSN_EPILOGUE_BEG)
at ../../gcc-head-src-orig/gcc/emit-rtl.c:4678
4678 {
(gdb) c
Continuing.
Breakpoint 4, final_scan_insn (insn=0x2a95dcc440, file=0x1083a10,
optimize=Variable "optimize" is not available.
)
at ../../gcc-head-src-orig/gcc/final.c:1895
1895 targetm.asm_out.function_begin_epilogue (file);
(gdb) print last_linenum
$4 = 24
(gdb) c
Continuing.
Breakpoint 4, final_scan_insn (insn=0x2a95dcc400, file=0x1083a10,
optimize=Variable "optimize" is not available.
)
at ../../gcc-head-src-orig/gcc/final.c:1895
1895 targetm.asm_out.function_begin_epilogue (file);
(gdb) print last_linenum
$5 = 24
[-- Attachment #2: argv.c.txt --]
[-- Type: text/plain, Size: 793 bytes --]
int gnat_argc = 0;
const char **gnat_argv = (const char **) 0;
const char **gnat_envp = (const char **) 0;
int
__gnat_arg_count (void)
{
return gnat_argc;
}
int
__gnat_len_arg (int arg_num)
{
if (gnat_argv != 0)
return __builtin_strlen (gnat_argv[arg_num]);
else
return 0;
}
void
__gnat_fill_arg (char *a, int i)
{
if (gnat_argv != 0)
__builtin_strncpy (a, gnat_argv[i], __builtin_strlen(gnat_argv[i]));
}
int
__gnat_env_count (void)
{
int i;
for (i = 0; gnat_envp[i]; i++)
;
return i;
}
int
__gnat_len_env (int env_num)
{
if (gnat_envp != 0)
return __builtin_strlen (gnat_envp[env_num]);
else
return 0;
}
void
__gnat_fill_env (char *a, int i)
{
if (gnat_envp != 0)
__builtin_strncpy (a, gnat_envp[i], __builtin_strlen (gnat_envp[i]));
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Multiple calls to case NOTE_INSN_EPILOGUE_BEG for same function?
2009-07-12 19:30 Multiple calls to case NOTE_INSN_EPILOGUE_BEG for same function? Douglas B Rupp
@ 2009-07-15 17:57 ` Richard Henderson
2009-07-15 19:36 ` Douglas B Rupp
2009-07-16 0:28 ` Douglas B Rupp
0 siblings, 2 replies; 6+ messages in thread
From: Richard Henderson @ 2009-07-15 17:57 UTC (permalink / raw)
To: Douglas B Rupp; +Cc: gcc
On 07/12/2009 12:30 PM, Douglas B Rupp wrote:
>
> I've been working on bringing the VMS patches up to date. The VMS
> Debugger requires a label at end prologue and begin_epilogue, and the
> fact that final_scan_insn makes multiple calls to NOTE_INSN_EPILOGUE_BEG
> for the same function makes this awkward. I suppose it could be case
> that there are multiple epilogues in a function, but the generated
> assembly code doesn't seem to indicate this. Below is an excerpt from a
> gdb session, and attached is a file derived from argv.c.
There really are multiple epilogues. The compiler is quite happy to
generate those, and has been happy to do so for some time.
What has changed is that we're now bothering to tell the debug info
about these epilogue copies. Since they're all copies of the same code,
it's not surprising at all that they're all given the same line number;
indeed, it would be surprising if that were not so.
If the VMS debugger can't handle multiple epilogues from a function, the
only thing I can suggest is that the VMS debug hooks discard info from
all but the first epilogue. Not very satisfactory, but you're no worse
off than you were before the change.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Multiple calls to case NOTE_INSN_EPILOGUE_BEG for same function?
2009-07-15 17:57 ` Richard Henderson
@ 2009-07-15 19:36 ` Douglas B Rupp
2009-07-16 0:28 ` Douglas B Rupp
1 sibling, 0 replies; 6+ messages in thread
From: Douglas B Rupp @ 2009-07-15 19:36 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc
Richard Henderson wrote:
> On 07/12/2009 12:30 PM, Douglas B Rupp wrote:
> There really are multiple epilogues. The compiler is quite happy to
> generate those, and has been happy to do so for some time.
>
> What has changed is that we're now bothering to tell the debug info
> about these epilogue copies. Since they're all copies of the same code,
> it's not surprising at all that they're all given the same line number;
> indeed, it would be surprising if that were not so.
>
> If the VMS debugger can't handle multiple epilogues from a function, the
> only thing I can suggest is that the VMS debug hooks discard info from
> all but the first epilogue. Not very satisfactory, but you're no worse
> off than you were before the change.
The VMS Debug ABI can handle multiple epilogues, but I haven't
implemented it yet in dwarf2out.c. My issue is that where the labels
are appearing don't all look like epilogues to me. If you don't mind
I'll send you some assembly code to illustrate.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Multiple calls to case NOTE_INSN_EPILOGUE_BEG for same function?
2009-07-15 17:57 ` Richard Henderson
2009-07-15 19:36 ` Douglas B Rupp
@ 2009-07-16 0:28 ` Douglas B Rupp
2009-07-16 15:09 ` Richard Henderson
1 sibling, 1 reply; 6+ messages in thread
From: Douglas B Rupp @ 2009-07-16 0:28 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
LEB0 and LEB1 are duplicated in the attached ivms assembly file from
libgcc2. Note the first occurrence of each is at the prologue end,
which makes no sense to me.
FYI: I'm emitting the LPE labels at NOTE_INSN_FUNCTION_BEG and the LEB
labels at NOTE_INSN_EPILOGUE_BEG. I can send you the full patch if you
like.
I deleted the .debug* sections to reduce the size of the file.
[-- Attachment #2: libgcc2.s.txt --]
[-- Type: text/plain, Size: 2850 bytes --]
.file "libgcc2.c"
.pred.safe_across_calls p1-p5,p16-p63
.section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
.section .debug_info,"",@progbits
.Ldebug_info0:
.section .debug_line,"",@progbits
.Ldebug_line0:
.text
.Ltext0:
.align 16
.align 64
.global __addvdi3#
.type __addvdi3#, @function
.hidden __addvdi3#
.proc __addvdi3#
__addvdi3:
[.LFB0:]
.file 1 "../../../gcc-head-src/libgcc/../gcc/libgcc2.c"
.loc 1 82 0
.prologue 12, 34
[.LPE0:]
[.LEB0:]
.mmb
.save ar.pfs, r35
alloc r35 = ar.pfs, 2, 3, 0, 0
.loc 1 83 0
add r8 = r33, r32
.loc 1 85 0
nop 0
.mib
cmp.gt p6, p7 = r0, r33
.loc 1 82 0
.save rp, r34
mov r34 = b0
.body
.loc 1 85 0
(p6) br.cond.dpnt .L2
;;
.mmi
cmp.gt p6, p7 = r32, r8
;;
(p6) addl r14 = 1, r0
(p7) mov r14 = r0
;;
.mmi
nop 0
cmp4.eq p6, p7 = 0, r14
.loc 1 86 0
nop 0
;;
.mib
(p7) mov r25 = r0
nop 0
.pred.safe_across_calls p1-p63
(p7) br.call.spnt.many b0 = abort#
.pred.safe_across_calls p1-p5,p16-p63
.loc 1 89 0
;;
.mii
nop 0
mov ar.pfs = r35
nop 0
;;
.mib
nop 0
mov b0 = r34
br.ret.sptk.many b0
.L2:
.loc 1 85 0
.mmi
cmp.lt p6, p7 = r32, r8
;;
(p6) addl r14 = 1, r0
(p7) mov r14 = r0
;;
.mmi
nop 0
cmp4.eq p6, p7 = 0, r14
.loc 1 86 0
nop 0
;;
.mib
(p7) mov r25 = r0
nop 0
.pred.safe_across_calls p1-p63
(p7) br.call.spnt.many b0 = abort#
.pred.safe_across_calls p1-p5,p16-p63
.loc 1 89 0
;;
.mii
nop 0
[.LEB0:]
mov ar.pfs = r35
nop 0
;;
.mib
nop 0
mov b0 = r34
br.ret.sptk.many b0
.LFE0:
.endp __addvdi3#
.align 16
.align 64
.global __addvsi3#
.type __addvsi3#, @function
.hidden __addvsi3#
.proc __addvsi3#
__addvsi3:
[.LFB1:]
.loc 1 93 0
.prologue 12, 34
[.LPE1:]
[.LEB1:]
.mmb
.save ar.pfs, r35
alloc r35 = ar.pfs, 2, 3, 0, 0
.loc 1 96 0
cmp4.gt p6, p7 = r0, r33
.loc 1 94 0
nop 0
.mib
add r33 = r33, r32
.loc 1 93 0
.save rp, r34
mov r34 = b0
.body
.loc 1 96 0
(p6) br.cond.dpnt .L8
;;
.mmi
cmp4.gt p6, p7 = r32, r33
;;
(p6) addl r14 = 1, r0
(p7) mov r14 = r0
;;
.mmi
nop 0
cmp4.eq p6, p7 = 0, r14
.loc 1 97 0
nop 0
;;
.mib
(p7) mov r25 = r0
nop 0
.pred.safe_across_calls p1-p63
(p7) br.call.spnt.many b0 = abort#
.pred.safe_across_calls p1-p5,p16-p63
.loc 1 100 0
;;
.mii
nop 0
mov ar.pfs = r35
sxt4 r8 = r33
;;
.mib
nop 0
mov b0 = r34
br.ret.sptk.many b0
.L8:
.loc 1 96 0
.mmi
cmp4.lt p6, p7 = r32, r33
;;
(p6) addl r14 = 1, r0
(p7) mov r14 = r0
;;
.mmi
nop 0
cmp4.eq p6, p7 = 0, r14
.loc 1 97 0
nop 0
;;
.mib
(p7) mov r25 = r0
nop 0
.pred.safe_across_calls p1-p63
(p7) br.call.spnt.many b0 = abort#
.pred.safe_across_calls p1-p5,p16-p63
.loc 1 100 0
;;
.mii
nop 0
[.LEB1:]
mov ar.pfs = r35
sxt4 r8 = r33
;;
.mib
nop 0
mov b0 = r34
br.ret.sptk.many b0
.LFE1:
.endp __addvsi3#
.Letext0:
.file 2 "../../../gcc-head-src/libgcc/../gcc/libgcc2.h"
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Multiple calls to case NOTE_INSN_EPILOGUE_BEG for same function?
2009-07-16 0:28 ` Douglas B Rupp
@ 2009-07-16 15:09 ` Richard Henderson
2009-07-16 15:20 ` Douglas B Rupp
0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2009-07-16 15:09 UTC (permalink / raw)
To: Douglas B Rupp; +Cc: gcc
On 07/15/2009 05:27 PM, Douglas B Rupp wrote:
> LEB0 and LEB1 are duplicated in the attached ivms assembly file from
> libgcc2. Note the first occurrence of each is at the prologue end, which
> makes no sense to me.
>
> FYI: I'm emitting the LPE labels at NOTE_INSN_FUNCTION_BEG and the LEB
> labels at NOTE_INSN_EPILOGUE_BEG. I can send you the full patch if you
> like.
>
> I deleted the .debug* sections to reduce the size of the file.
Hmm. It looks like sched-ebb is moving the epilogue note farther away
from the epilogue than I expected. Since only ia64 uses this scheduler,
I hadn't noticed. I wonder what's the easiest way to handle this.
As for the fact that they're both labeled .LEB0... that's surely an ia64
backend bug. Certainly there's no such problem with the generic dwarf2
output; if there were such a problem it would be preventing x86 bootstrap.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Multiple calls to case NOTE_INSN_EPILOGUE_BEG for same function?
2009-07-16 15:09 ` Richard Henderson
@ 2009-07-16 15:20 ` Douglas B Rupp
0 siblings, 0 replies; 6+ messages in thread
From: Douglas B Rupp @ 2009-07-16 15:20 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc
Richard Henderson wrote:
> On 07/15/2009 05:27 PM, Douglas B Rupp wrote:
>> LEB0 and LEB1 are duplicated in the attached ivms assembly file from
>> libgcc2. Note the first occurrence of each is at the prologue end, which
>> makes no sense to me.
>>
>> FYI: I'm emitting the LPE labels at NOTE_INSN_FUNCTION_BEG and the LEB
>> labels at NOTE_INSN_EPILOGUE_BEG. I can send you the full patch if you
>> like.
>>
>> I deleted the .debug* sections to reduce the size of the file.
>
> Hmm. It looks like sched-ebb is moving the epilogue note farther away
> from the epilogue than I expected. Since only ia64 uses this scheduler,
> I hadn't noticed. I wonder what's the easiest way to handle this.
>
> As for the fact that they're both labeled .LEB0... that's surely an ia64
> backend bug. Certainly there's no such problem with the generic dwarf2
> output; if there were such a problem it would be preventing x86 bootstrap.
Your right, the labeling is purely contrived to illustrate the problem.
I can fix that bug by implementing the multiple epilogue ABI for VMS.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-07-16 15:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-12 19:30 Multiple calls to case NOTE_INSN_EPILOGUE_BEG for same function? Douglas B Rupp
2009-07-15 17:57 ` Richard Henderson
2009-07-15 19:36 ` Douglas B Rupp
2009-07-16 0:28 ` Douglas B Rupp
2009-07-16 15:09 ` Richard Henderson
2009-07-16 15:20 ` Douglas B Rupp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).