fix sjlj eh vs dwarf2 debug

fix sjlj eh vs dwarf2 debug

[Richard Henderson]

Targets using sjlj eh with dwarf2 debugging would get confused and
emit unwind data in .eh_frame instead of .debug_frame.  Which likely
would have gone unnoticed were it not for the fact that .eh_frame
has some extra augmentation data, which results in the assembly
containing references to undefined symbols.

Applied to mainline.  Ok for branch?


r~


        * dwarf2out.c (dwarf2out_frame_finish): Never emit .eh_frame
        if USING_SJLJ_EXCEPTIONS.

Index: dwarf2out.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/dwarf2out.c,v
retrieving revision 1.167
diff -c -p -d -r1.167 dwarf2out.c
*** dwarf2out.c	2001/08/06 15:20:48	1.167
--- dwarf2out.c	2001/08/14 19:09:20
*************** dwarf2out_frame_finish ()
*** 2098,2109 ****
  #ifdef MIPS_DEBUGGING_INFO
    if (write_symbols == DWARF2_DEBUG)
      output_call_frame_info (0);
!   if (flag_unwind_tables || (flag_exceptions && ! USING_SJLJ_EXCEPTIONS))
      output_call_frame_info (1);
  #else
!   if (write_symbols == DWARF2_DEBUG
!       || flag_unwind_tables || (flag_exceptions && ! USING_SJLJ_EXCEPTIONS))
!     output_call_frame_info (1);
  #endif
  }
  \f
--- 2098,2110 ----
  #ifdef MIPS_DEBUGGING_INFO
    if (write_symbols == DWARF2_DEBUG)
      output_call_frame_info (0);
!   if (! USING_SJLJ_EXCEPTIONS && (flag_unwind_tables || flag_exceptions))
      output_call_frame_info (1);
  #else
!   int for_eh = (! USING_SJLJ_EXCEPTIONS
! 		&& (flag_unwind_tables || flag_exceptions));
!   if (write_symbols == DWARF2_DEBUG || for_eh)
!     output_call_frame_info (for_eh);
  #endif
  }
  \f

Re: fix sjlj eh vs dwarf2 debug

[Richard Henderson]

On Tue, Aug 14, 2001 at 12:16:28PM -0700, Richard Henderson wrote:
>         * dwarf2out.c (dwarf2out_frame_finish): Never emit .eh_frame
>         if USING_SJLJ_EXCEPTIONS.

Actually, I take that back.  Now that we are (or may be) encoding
.eh_frame data in non-standard ways, we should probably not try to
emit only one of .eh_frame or .debug_frame.  That way the debugger
doesn't have to care about whatever funnies we do with augmentation.

Jason, what are your thoughts?


r~

Re: fix sjlj eh vs dwarf2 debug

[Jason Merrill]

>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:

> On Tue, Aug 14, 2001 at 12:16:28PM -0700, Richard Henderson wrote:
>> * dwarf2out.c (dwarf2out_frame_finish): Never emit .eh_frame
>> if USING_SJLJ_EXCEPTIONS.

> Actually, I take that back.  Now that we are (or may be) encoding
> .eh_frame data in non-standard ways, we should probably not try to
> emit only one of .eh_frame or .debug_frame.  That way the debugger
> doesn't have to care about whatever funnies we do with augmentation.

> Jason, what are your thoughts?

That makes sense to me.  What do gdb folks think?

Jason

Re: fix sjlj eh vs dwarf2 debug

[Andrew Cagney]

>>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:
> 
> 
>> On Tue, Aug 14, 2001 at 12:16:28PM -0700, Richard Henderson wrote:
> 
>>> * dwarf2out.c (dwarf2out_frame_finish): Never emit .eh_frame
>>> if USING_SJLJ_EXCEPTIONS.
> 
> 
>> Actually, I take that back.  Now that we are (or may be) encoding
>> .eh_frame data in non-standard ways, we should probably not try to
>> emit only one of .eh_frame or .debug_frame.  That way the debugger
>> doesn't have to care about whatever funnies we do with augmentation.
> 
> 
>> Jason, what are your thoughts?
> 
> 
> That makes sense to me.  What do gdb folks think?

This won't affect GDB(1). I'd go with what ever the current 
interpretation of the standards are.

	Andrew

(1) because as far as I can tell, no one has extended GDB's throw/catch 
code (contributed by HP) to support anything beyond HP's C++ compiler.

Re: fix sjlj eh vs dwarf2 debug

[Richard Henderson]

On Wed, Aug 22, 2001 at 11:28:36PM -0400, Andrew Cagney wrote:
> (1) because as far as I can tell, no one has extended GDB's throw/catch 
> code (contributed by HP) to support anything beyond HP's C++ compiler.

That is actually irrelevant.  The place gdb should be using .debug_frame
is instead of code reading for the prologue.


r~

Re: fix sjlj eh vs dwarf2 debug

[Jason Merrill]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:

>>>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:
>> 
>>> On Tue, Aug 14, 2001 at 12:16:28PM -0700, Richard Henderson wrote:
>> 
>>>> * dwarf2out.c (dwarf2out_frame_finish): Never emit .eh_frame
>>>> if USING_SJLJ_EXCEPTIONS.
>> 
>>> Actually, I take that back.  Now that we are (or may be) encoding
>>> .eh_frame data in non-standard ways, we should probably not try to
>>> emit only one of .eh_frame or .debug_frame.  That way the debugger
>>> doesn't have to care about whatever funnies we do with augmentation.
>> 
>>> Jason, what are your thoughts?
>> That makes sense to me.  What do gdb folks think?

> This won't affect GDB(1). I'd go with what ever the current interpretation
> of the standards are.

.debug_frame is part of the DWARF 2 standard; .eh_frame is our own
modification of that format for use in a loaded section, for which there is
no standard but gcc.

Jason

Re: fix sjlj eh vs dwarf2 debug

[Daniel Berlin]

Andrew Cagney <ac131313@cygnus.com> writes:

>>>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:
>>
>>> On Tue, Aug 14, 2001 at 12:16:28PM -0700, Richard Henderson wrote:
>>
>>>> * dwarf2out.c (dwarf2out_frame_finish): Never emit .eh_frame
>>>> if USING_SJLJ_EXCEPTIONS.
>>
>>> Actually, I take that back.  Now that we are (or may be) encoding
>>> .eh_frame data in non-standard ways, we should probably not try to
>>> emit only one of .eh_frame or .debug_frame.  That way the debugger
>>> doesn't have to care about whatever funnies we do with augmentation.
>>
>>> Jason, what are your thoughts?
>> That makes sense to me.  What do gdb folks think?
>
> This won't affect GDB(1). I'd go with what ever the current
> interpretation of the standards are.
>
> 	Andrew
>
> (1) because as far as I can tell, no one has extended GDB's
>     throw/catch code (contributed by HP) to support anything beyond
>     HP's C++ compiler.

Err, look at a patch i submitted about a year ago to extend it to
support gcc's throw/catch model through stupid stack frame tricks and
breakpointing __throw and __catch.

>

-- 
"I went down the street to the 24-hour grocery.  When I got
there, the guy was locking the front door.  I said, "Hey, the
sign says you're open 24 hours."  He said, "Yes, but not in a
row."
"-Steven Wright