public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Reentering sections
@ 2001-09-21  5:22 Roman Lechtchinsky
  2001-09-21 10:36 ` Richard Henderson
  0 siblings, 1 reply; 4+ messages in thread
From: Roman Lechtchinsky @ 2001-09-21  5:22 UTC (permalink / raw)
  To: gcc

Hi,

the function output_function_exception_table in except.c first opens an
exception section and then, after outputting the exception table, reenters
the function section for the function to which the table belongs. This
doesn't work on the Cray T3E since the assembler doesn't support reopening
sections. Is this behavior actually necessary (the entire function body is
output before output_function_exception_table is called, AFAICS) or is the
call to function_section bogus?

Bye

Roman


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Reentering sections
  2001-09-21  5:22 Reentering sections Roman Lechtchinsky
@ 2001-09-21 10:36 ` Richard Henderson
  2001-09-26  5:14   ` Roman Lechtchinsky
  0 siblings, 1 reply; 4+ messages in thread
From: Richard Henderson @ 2001-09-21 10:36 UTC (permalink / raw)
  To: Roman Lechtchinsky; +Cc: gcc

On Fri, Sep 21, 2001 at 02:18:09PM +0200, Roman Lechtchinsky wrote:
> Is this behavior actually necessary (the entire function body is
> output before output_function_exception_table is called, AFAICS) or is the
> call to function_section bogus?

As currently configured, we have yet to do assemble_end_function,
which does need to be in function_section.  The reason that we do
that is that IA-64 has special assembler directives to emit EH
table info, like so:

	.proc foo
foo:
	[ code ]
	.handlerdata
	[ eh data ]
	.endp foo

where ".endp" is emitted by ASM_DECLARE_FUNCTION_SIZE in 
assemble_end_function.

It should be possible to rearrange this based on IA64_UNWIND_INFO.


r~

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Reentering sections
  2001-09-21 10:36 ` Richard Henderson
@ 2001-09-26  5:14   ` Roman Lechtchinsky
  2001-09-26 12:46     ` Richard Henderson
  0 siblings, 1 reply; 4+ messages in thread
From: Roman Lechtchinsky @ 2001-09-26  5:14 UTC (permalink / raw)
  To: Richard Henderson; +Cc: gcc

On Fri, 21 Sep 2001, Richard Henderson wrote:
> > Is this behavior actually necessary (the entire function body is
> > output before output_function_exception_table is called, AFAICS) or is the
> > call to function_section bogus?
> 
> As currently configured, we have yet to do assemble_end_function,
> which does need to be in function_section.
> [...]
> It should be possible to rearrange this based on IA64_UNWIND_INFO.

Yep, there is one more problem, though. (*debug_hooks->function_decl) is
called after output_function_exception_table, but it needs to be in the
function section. Can it be output directly after assemle_end_function,
i.e. before the exception table on non-IA64_UNWIND_INFO architectures?

Bye

Roman


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Reentering sections
  2001-09-26  5:14   ` Roman Lechtchinsky
@ 2001-09-26 12:46     ` Richard Henderson
  0 siblings, 0 replies; 4+ messages in thread
From: Richard Henderson @ 2001-09-26 12:46 UTC (permalink / raw)
  To: Roman Lechtchinsky; +Cc: gcc

On Wed, Sep 26, 2001 at 02:09:16PM +0200, Roman Lechtchinsky wrote:
> Yep, there is one more problem, though. (*debug_hooks->function_decl) is
> called after output_function_exception_table, but it needs to be in the
> function section. Can it be output directly after assemle_end_function,
> i.e. before the exception table on non-IA64_UNWIND_INFO architectures?

Yes.


r~

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-09-26 12:46 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-09-21  5:22 Reentering sections Roman Lechtchinsky
2001-09-21 10:36 ` Richard Henderson
2001-09-26  5:14   ` Roman Lechtchinsky
2001-09-26 12:46     ` Richard Henderson

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).