public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: .eh_frame section
@ 1997-10-08 15:38 meissner
  1997-10-08 21:19 ` Richard Henderson
  0 siblings, 1 reply; 13+ messages in thread
From: meissner @ 1997-10-08 15:38 UTC (permalink / raw)
  To: jason, rth; +Cc: egcs, haible

| On Tue, Oct 07, 1997 at 10:42:08PM -0700, Jason Merrill wrote:
| > Richard was muttering something about a possibly suitable reloc style the
| > other day, but I don't remember the upshot.
| 
| Most architectures have a word sized pc-relative relocation, but few
| (none?) provide a pseudo-op to use it.  So there we are.

On the other hand, doing:

	.long .-label

(or .word, .etc.) will often times generate the approprate relocation.

You can even say:

	.L1:
		.long .L1-label1
		.long .L1-label2
		.long .L1-label3

for switch statements that contain PC-relative offsets.

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

* Re: .eh_frame section
  1997-10-08 15:38 .eh_frame section meissner
@ 1997-10-08 21:19 ` Richard Henderson
  1997-10-09  9:26   ` Ian Lance Taylor
  0 siblings, 1 reply; 13+ messages in thread
From: Richard Henderson @ 1997-10-08 21:19 UTC (permalink / raw)
  To: meissner; +Cc: jason, rth, egcs, haible

On Wed, Oct 08, 1997 at 06:38:03PM -0400, meissner@cygnus.com wrote:
> | Most architectures have a word sized pc-relative relocation, but few
> | (none?) provide a pseudo-op to use it.  So there we are.
> 
> On the other hand, doing:
> 
> 	.long .-label
> 
> (or .word, .etc.) will often times generate the approprate relocation.

When "label" is external, no assembler I've found can handle it.
I tried gas (alpha, i386), Irix 6, Solaris 2.5, DU 4.0b.

The last two were cute in that they didn't complain, but neither
did they generate a reloc of any sort.


r~

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

* Re: .eh_frame section
  1997-10-08 21:19 ` Richard Henderson
@ 1997-10-09  9:26   ` Ian Lance Taylor
  1997-10-09  9:26     ` Jason Merrill
  0 siblings, 1 reply; 13+ messages in thread
From: Ian Lance Taylor @ 1997-10-09  9:26 UTC (permalink / raw)
  To: rth; +Cc: meissner, jason, rth, egcs, haible

   Date: Wed, 8 Oct 1997 16:49:24 -0700
   From: Richard Henderson <rth@cygnus.com>

   On Wed, Oct 08, 1997 at 06:38:03PM -0400, meissner@cygnus.com wrote:
   > | Most architectures have a word sized pc-relative relocation, but few
   > | (none?) provide a pseudo-op to use it.  So there we are.
   > 
   > On the other hand, doing:
   > 
   > 	.long .-label
   > 
   > (or .word, .etc.) will often times generate the approprate relocation.

   When "label" is external, no assembler I've found can handle it.
   I tried gas (alpha, i386), Irix 6, Solaris 2.5, DU 4.0b.

Not too surprising, since that's a reverse PC relative reloc.  You
could only get a proper PC relative reloc by doing
    .long label-.
However, many assemblers don't support that either.

Incidentally, if the DWARF spec requires that the value be an offset
from the start of the section, and we're generating an absolute
address, then we're already violating the spec.  I don't know much
about DWARF, but it sounds like they didn't consider the case of
loading the information into memory with the program.

Ian

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

* Re: .eh_frame section
  1997-10-09  9:26   ` Ian Lance Taylor
@ 1997-10-09  9:26     ` Jason Merrill
  1997-10-10 17:21       ` Bruno Haible
  0 siblings, 1 reply; 13+ messages in thread
From: Jason Merrill @ 1997-10-09  9:26 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: rth, meissner, egcs, haible

>>>>> Ian Lance Taylor <ian@cygnus.com> writes:

> Incidentally, if the DWARF spec requires that the value be an offset
> from the start of the section, and we're generating an absolute
> address, then we're already violating the spec.

But we're also putting the info in a different section, so it doesn't
really matter.

> I don't know much about DWARF, but it sounds like they didn't consider
> the case of loading the information into memory with the program.

Yep.

Jason

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

* Re: .eh_frame section
  1997-10-09  9:26     ` Jason Merrill
@ 1997-10-10 17:21       ` Bruno Haible
  1997-10-13  9:44         ` Joern Rennecke
  0 siblings, 1 reply; 13+ messages in thread
From: Bruno Haible @ 1997-10-10 17:21 UTC (permalink / raw)
  To: Jason Merrill; +Cc: Ian Lance Taylor, rth, meissner, egcs

Jason Merrill writes:
> 
> > Incidentally, if the DWARF spec requires ...
> 
> But we're also putting the info in a different section, so it doesn't
> really matter.

Fine. So we can replace absolute labels by label differences. I propose
the following: When the compiler output contains either a .gcc_except or
a .eh_table section, the beginning of the text section for this module
is marked as __TEXT_BEGIN__ and subtracted from all labels in the tables.
A new section .text_begin is created which only contains the absolute
__TEXT_BEGIN__.

The code which interprets these tables (in frame.c) would have to make
use of the fact that the words in the .text_begin section are in one-one
correspondance with the dwarf2 table (and that the linker doesn't change
the order of the words within the .text_begin section).

This way, we increase the total executable size by 0.5 percent, but
the .gcc_except and .eh_table (25 percent) won't contain relocations
and can therefore be marked read-only ("a" instead of "aw"). This will
make exception handling more acceptable to people.

                          Bruno


Below is an unfinished hack in this direction, just to illustrate what
I mean.

*** dwarf2out.c.bak	Fri Oct  3 01:22:48 1997
--- dwarf2out.c	Fri Oct 10 10:49:41 1997
***************
*** 1513,1526 ****
        ASM_OUTPUT_LABEL (asm_out_file, l1);
  
        if (for_eh)
! 	ASM_OUTPUT_DWARF_ADDR (asm_out_file, "__FRAME_BEGIN__");
        else
  	ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (FRAME_SECTION));
        if (flag_debug_asm)
  	fprintf (asm_out_file, "\t%s FDE CIE offset", ASM_COMMENT_START);
  
        fputc ('\n', asm_out_file);
!       ASM_OUTPUT_DWARF_ADDR (asm_out_file, fde->dw_fde_begin);
        if (flag_debug_asm)
  	fprintf (asm_out_file, "\t%s FDE initial location", ASM_COMMENT_START);
  
--- 1513,1531 ----
        ASM_OUTPUT_LABEL (asm_out_file, l1);
  
        if (for_eh)
! 	ASM_OUTPUT_DWARF_ADDR_DELTA (asm_out_file,
! 				     "__FRAME_BEGIN__", "__FRAME_BEGIN__");
        else
  	ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (FRAME_SECTION));
        if (flag_debug_asm)
  	fprintf (asm_out_file, "\t%s FDE CIE offset", ASM_COMMENT_START);
  
        fputc ('\n', asm_out_file);
!       if (for_eh)
! 	ASM_OUTPUT_DWARF_ADDR_DELTA (asm_out_file,
! 				     fde->dw_fde_begin, "__TEXT_BEGIN__");
!       else
! 	ASM_OUTPUT_DWARF_ADDR (asm_out_file, fde->dw_fde_begin);
        if (flag_debug_asm)
  	fprintf (asm_out_file, "\t%s FDE initial location", ASM_COMMENT_START);
  
***************
*** 1535,1541 ****
  	{
  	  /* For now, a pointer to the translation unit's info will do.
  	     ??? Eventually this should point to the function's info.  */
! 	  ASM_OUTPUT_DWARF_ADDR (asm_out_file, "__EXCEPTION_TABLE__");
  	  if (flag_debug_asm)
  	    fprintf (asm_out_file, "\t%s pointer to exception region info",
  		     ASM_COMMENT_START);
--- 1540,1547 ----
  	{
  	  /* For now, a pointer to the translation unit's info will do.
  	     ??? Eventually this should point to the function's info.  */
! 	  ASM_OUTPUT_DWARF_ADDR_DELTA (asm_out_file, "__EXCEPTION_TABLE__",
! 						     "__EXCEPTION_TABLE__");
  	  if (flag_debug_asm)
  	    fprintf (asm_out_file, "\t%s pointer to exception region info",
  		     ASM_COMMENT_START);
*** toplev.c.bak	Sat Sep 27 01:34:30 1997
--- toplev.c	Fri Oct 10 11:23:48 1997
***************
*** 2404,2409 ****
--- 2404,2419 ----
    if (write_symbols == DWARF2_DEBUG)
      TIMEVAR (symout_time, dwarf2out_init (asm_out_file, main_input_filename));
  #endif
+ #if 1
+   if (!output_bytecode)
+     {
+       text_section ();
+       assemble_label ("__TEXT_BEGIN__");
+       named_section (NULL, ".text_begin", 1);
+       assemble_integer (gen_rtx (SYMBOL_REF, Pmode, "__TEXT_BEGIN__"),
+ 			POINTER_SIZE / BITS_PER_UNIT, 1);
+     }
+ #endif
  
    /* Initialize yet another pass.  */
  
*** except.c.bak	Fri Oct  3 12:24:30 1997
--- except.c	Fri Oct 10 11:39:04 1997
***************
*** 1541,1554 ****
--- 1541,1560 ----
  
    ASM_GENERATE_INTERNAL_LABEL (buf, "LEHB", n);
    sym = gen_rtx (SYMBOL_REF, Pmode, buf);
+   sym = gen_rtx (MINUS, Pmode, sym,
+ 			       gen_rtx (SYMBOL_REF, Pmode, "__TEXT_BEGIN__"));
    assemble_integer (sym, POINTER_SIZE / BITS_PER_UNIT, 1);
  
    ASM_GENERATE_INTERNAL_LABEL (buf, "LEHE", n);
    sym = gen_rtx (SYMBOL_REF, Pmode, buf);
+   sym = gen_rtx (MINUS, Pmode, sym,
+ 			       gen_rtx (SYMBOL_REF, Pmode, "__TEXT_BEGIN__"));
    assemble_integer (sym, POINTER_SIZE / BITS_PER_UNIT, 1);
  
    ASM_GENERATE_INTERNAL_LABEL (buf, "L", n);
    sym = gen_rtx (SYMBOL_REF, Pmode, buf);
+   sym = gen_rtx (MINUS, Pmode, sym,
+ 			       gen_rtx (SYMBOL_REF, Pmode, "__TEXT_BEGIN__"));
    assemble_integer (sym, POINTER_SIZE / BITS_PER_UNIT, 1);
  
    putc ('\n', file);		/* blank line */
***************
*** 1562,1580 ****
    int i;
    extern FILE *asm_out_file;
  
-   if (! doing_eh (0) || ! eh_table)
-     return;
- 
    exception_section ();
  
    /* Beginning marker for table.  */
    assemble_align (GET_MODE_ALIGNMENT (ptr_mode));
    assemble_label ("__EXCEPTION_TABLE__");
  
!   for (i = 0; i < eh_table_size; ++i)
!     output_exception_table_entry (asm_out_file, eh_table[i]);
  
!   free (eh_table);
  
    /* Ending marker for table.  */
    assemble_label ("__EXCEPTION_END__");
--- 1568,1586 ----
    int i;
    extern FILE *asm_out_file;
  
    exception_section ();
  
    /* Beginning marker for table.  */
    assemble_align (GET_MODE_ALIGNMENT (ptr_mode));
    assemble_label ("__EXCEPTION_TABLE__");
  
!   if (doing_eh (0) && eh_table)
!     {
!       for (i = 0; i < eh_table_size; ++i)
! 	output_exception_table_entry (asm_out_file, eh_table[i]);
  
!       free (eh_table);
!     }
  
    /* Ending marker for table.  */
    assemble_label ("__EXCEPTION_END__");


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

* Re: .eh_frame section
  1997-10-10 17:21       ` Bruno Haible
@ 1997-10-13  9:44         ` Joern Rennecke
  1997-10-13 13:41           ` Richard Henderson
  0 siblings, 1 reply; 13+ messages in thread
From: Joern Rennecke @ 1997-10-13  9:44 UTC (permalink / raw)
  To: Bruno Haible; +Cc: jason, ian, rth, meissner, egcs

> Fine. So we can replace absolute labels by label differences. I propose
> the following: When the compiler output contains either a .gcc_except or
> a .eh_table section, the beginning of the text section for this module
> is marked as __TEXT_BEGIN__ and subtracted from all labels in the tables.
> A new section .text_begin is created which only contains the absolute
> __TEXT_BEGIN__.

This doesn't sound like it'll work with linker relaxation, unless you
want to add a lot of extra code to the linker to decode this information,
translate it into proper relocations, and re-encode it after its
processing is done.

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

* Re: .eh_frame section
  1997-10-13  9:44         ` Joern Rennecke
@ 1997-10-13 13:41           ` Richard Henderson
  0 siblings, 0 replies; 13+ messages in thread
From: Richard Henderson @ 1997-10-13 13:41 UTC (permalink / raw)
  To: Joern Rennecke; +Cc: Bruno Haible, jason, ian, rth, meissner, egcs

On Mon, Oct 13, 1997 at 05:42:37PM +0100, Joern Rennecke wrote:
> > Fine. So we can replace absolute labels by label differences. I propose
> > the following: When the compiler output contains either a .gcc_except or
> > a .eh_table section, the beginning of the text section for this module
> > is marked as __TEXT_BEGIN__ and subtracted from all labels in the tables.
> > A new section .text_begin is created which only contains the absolute
> > __TEXT_BEGIN__.
> 
> This doesn't sound like it'll work with linker relaxation, unless you
> want to add a lot of extra code to the linker to decode this information,
> translate it into proper relocations, and re-encode it after its
> processing is done.

Actually, it's not going to work at all except on Irix6 and OSF/1.  No 
one else has the relocations to subtract symbols at link time vs asm time.


r~

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

* Re: .eh_frame section
  2007-05-29 23:13 ` Ian Lance Taylor
@ 2007-05-30  7:41   ` sfora dim
  0 siblings, 0 replies; 13+ messages in thread
From: sfora dim @ 2007-05-30  7:41 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: gcc

On 29 May 2007 15:27:43 -0700, Ian Lance Taylor <iant@google.com> wrote:
> > I wonder why when I compile standard C programs using "gcc -v simple.c"
> > I can see that the linker adds the "--eh-frame-hdr" parameter ?
>
> That option is always used if the linker supports it.
>
> > After all there is no use for the eh section when we don't support
> > exceptions, no ?
>
> Ideally the linker would not generate an EH header if there is no
> exception frame information.
>
> It is possible to use gcc to link C++ code, and it is desirable to
> always create an EH header if there is any exception frame
> information, so if there is a problem here I think it should be fixed
> in the linker.

I don't know if it is a problem. If it's a pure C program, and we're giving
the linker the "--eh-frame-hdr" - does it still generate the EH header ?
if so - does it waste memory ?
if yes, maybe the gcc driver should pass that parameter to the linker only
when there really is exception frame information ?

thank you
sfora
>
> Ian
>

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

* Re: .eh_frame section
  2007-05-29 21:33 sfora dim
@ 2007-05-29 23:13 ` Ian Lance Taylor
  2007-05-30  7:41   ` sfora dim
  0 siblings, 1 reply; 13+ messages in thread
From: Ian Lance Taylor @ 2007-05-29 23:13 UTC (permalink / raw)
  To: sfora dim; +Cc: gcc

"sfora dim" <sfora.dim@gmail.com> writes:

> I read that the eh_frame is for exceptions support,
> for languages like C++ for instance.

Yes.

> I wonder why when I compile standard C programs using "gcc -v simple.c"
> I can see that the linker adds the "--eh-frame-hdr" parameter ?

That option is always used if the linker supports it.

> After all there is no use for the eh section when we don't support
> exceptions, no ?

Ideally the linker would not generate an EH header if there is no
exception frame information.

It is possible to use gcc to link C++ code, and it is desirable to
always create an EH header if there is any exception frame
information, so if there is a problem here I think it should be fixed
in the linker.

Ian

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

* .eh_frame section
@ 2007-05-29 21:33 sfora dim
  2007-05-29 23:13 ` Ian Lance Taylor
  0 siblings, 1 reply; 13+ messages in thread
From: sfora dim @ 2007-05-29 21:33 UTC (permalink / raw)
  To: gcc

Hello,

I read that the eh_frame is for exceptions support,
for languages like C++ for instance.

I wonder why when I compile standard C programs using "gcc -v simple.c"
I can see that the linker adds the "--eh-frame-hdr" parameter ?

After all there is no use for the eh section when we don't support
exceptions, no ?

thank you
sfora

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

* Re: .eh_frame section
  1997-10-07 23:14 ` Jason Merrill
@ 1997-10-08  9:24   ` Richard Henderson
  0 siblings, 0 replies; 13+ messages in thread
From: Richard Henderson @ 1997-10-08  9:24 UTC (permalink / raw)
  To: Jason Merrill; +Cc: Bruno Haible, egcs

On Tue, Oct 07, 1997 at 10:42:08PM -0700, Jason Merrill wrote:
> Richard was muttering something about a possibly suitable reloc style the
> other day, but I don't remember the upshot.

Most architectures have a word sized pc-relative relocation, but few
(none?) provide a pseudo-op to use it.  So there we are.


r~

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

* Re: .eh_frame section
  1997-10-07 23:14 Bruno Haible
@ 1997-10-07 23:14 ` Jason Merrill
  1997-10-08  9:24   ` Richard Henderson
  0 siblings, 1 reply; 13+ messages in thread
From: Jason Merrill @ 1997-10-07 23:14 UTC (permalink / raw)
  To: Bruno Haible, egcs

>>>>> Bruno Haible <haible@ilog.fr> writes:

>   2. The ".eh_frame" section takes up about 25% of an executable. For
>      an executable, this is nothing to worry about. But for a shared
>      library, "objdump --section-headers" shows that the .eh_frame
>      section has the attributes  CONTENTS, ALLOC, LOAD, RELOC, DATA.
>      The combination LOAD, RELOC means that, on most Unix systems,
>      this section will be completely read in and relocated when
>      the shared library is mapped into the process memory, i.e. usually
>      at program startup. Here at ILOG, we are routinely using executables
>      which are linked to a total of 20 MB of shared libraries. If 25%
>      of this must be read from disk each time the program starts up,
>      that will certainly be noticeable...

Agreed.

>      Would it be possible to replace the `pc_begin' pointer and the
>      `CIE_pointer' in `struct dwarf_fde' by position-independent entities?

That would be nice.  Anyone have suggestions?  The DWARF spec calls for the
CIE_pointer fields to be position-independent by making them offsets from
the beginning of the section (in the executable), but there's no way to
represent that in the assembler, so I changed it to a straight reloc.

Richard was muttering something about a possibly suitable reloc style the
other day, but I don't remember the upshot.

Jason

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

* .eh_frame section
@ 1997-10-07 23:14 Bruno Haible
  1997-10-07 23:14 ` Jason Merrill
  0 siblings, 1 reply; 13+ messages in thread
From: Bruno Haible @ 1997-10-07 23:14 UTC (permalink / raw)
  To: Jason Merrill

Hi,

Currently the ".eh_frame" section (containing DWARF2 unwind info) is
a read-write section. This poses two problems:

  1. Accidental write accesses to this area by buggy programs won't be
     caught. Instead such a program is likely to go to nirvana when the
     next __throw occurs.

Please find below a patch which makes the ".eh_frame" section read-only
when compiling non-PIC (on those systems for which I could guess how to
implement it).

  2. The ".eh_frame" section takes up about 25% of an executable. For
     an executable, this is nothing to worry about. But for a shared
     library, "objdump --section-headers" shows that the .eh_frame
     section has the attributes  CONTENTS, ALLOC, LOAD, RELOC, DATA.
     The combination LOAD, RELOC means that, on most Unix systems,
     this section will be completely read in and relocated when
     the shared library is mapped into the process memory, i.e. usually
     at program startup. Here at ILOG, we are routinely using executables
     which are linked to a total of 20 MB of shared libraries. If 25%
     of this must be read from disk each time the program starts up,
     that will certainly be noticeable...
     Would it be possible to replace the `pc_begin' pointer and the
     `CIE_pointer' in `struct dwarf_fde' by position-independent entities?

Best regards,
                    Bruno


Sun Oct  5 03:07:30 1997  Bruno Haible  <bruno@linuix.mathematik.uni-karlsruhe.de>

        * sysv4.h (EH_FRAME_SECTION_ASM_OP, READONLY_EH_FRAME_SECTION_ASM_OP):
        New macros.
        * sparc/sysv4.h (READONLY_EH_FRAME_SECTION_ASM_OP): Likewise.
        * mips/iris6.h (READONLY_EH_FRAME_SECTION_ASM_OP): Likewise.
        * varasm.c (eh_frame_section): Use READONLY_EH_FRAME_SECTION_ASM_OP
        unless compiling in PIC mode.
        * crtstuff.c: Likewise.


*** config/mips/iris6.h.bak	Sat Sep 27 01:33:40 1997
--- config/mips/iris6.h	Sun Oct  5 00:03:12 1997
***************
*** 251,256 ****
--- 251,257 ----
  /* dwarf2out will handle padding this data properly.  We definitely don't
     want it 8-byte aligned on n32.  */
  #define EH_FRAME_SECTION_ASM_OP ".section\t.eh_frame,1,2,0,1"
+ #define READONLY_EH_FRAME_SECTION_ASM_OP ".section\t.eh_frame,1,2,0,1"
  
  /* A default list of other sections which we might be "in" at any given
     time.  For targets that use additional sections (e.g. .tdesc) you
*** config/sparc/sysv4.h.bak	Sat Sep 27 01:35:49 1997
--- config/sparc/sysv4.h	Sat Oct  4 23:59:59 1997
***************
*** 177,182 ****
--- 177,184 ----
  #define DTORS_SECTION_ASM_OP    ".section\t\".dtors\",#alloc,#write"
  #undef EH_FRAME_SECTION_ASM_OP
  #define EH_FRAME_SECTION_ASM_OP ".section\t\".eh_frame\",#alloc,#write"
+ #undef READONLY_EH_FRAME_SECTION_ASM_OP
+ #define READONLY_EH_FRAME_SECTION_ASM_OP ".section\t\".eh_frame\",#alloc"
  
  /* A C statement to output something to the assembler file to switch to section
     NAME for object DECL which is either a FUNCTION_DECL, a VAR_DECL or
*** config/svr4.h.bak	Wed Apr 30 19:59:24 1997
--- config/svr4.h	Sun Oct  5 01:49:55 1997
***************
*** 527,532 ****
--- 527,539 ----
  #define CTORS_SECTION_ASM_OP	".section\t.ctors,\"aw\""
  #define DTORS_SECTION_ASM_OP	".section\t.dtors,\"aw\""
  
+ /* Put DWARF2 unwind info into a section with SHF_WRITE attribute set if
+    we are compiling for a shared library, but in a read-only section if we
+    are compiling code for an executable. */
+ 
+ #define EH_FRAME_SECTION_ASM_OP		".section\t.eh_frame,\"aw\""
+ #define READONLY_EH_FRAME_SECTION_ASM_OP ".section\t.eh_frame,\"a\""
+ 
  /* On svr4, we *do* have support for the .init and .fini sections, and we
     can put stuff in there to be executed before and after `main'.  We let
     crtstuff.c and other files know this by defining the following symbols.
*** crtstuff.c.bak	Sat Sep 27 01:33:59 1997
--- crtstuff.c	Sun Oct  5 01:10:57 1997
***************
*** 79,84 ****
--- 79,87 ----
  #if !defined (EH_FRAME_SECTION_ASM_OP) && defined (DWARF2_UNWIND_INFO) && defined(ASM_OUTPUT_SECTION_NAME)
  #define EH_FRAME_SECTION_ASM_OP	".section\t.eh_frame,\"aw\""
  #endif
+ #if !defined (READONLY_EH_FRAME_SECTION_ASM_OP) && defined (DWARF2_UNWIND_INFO) && defined(ASM_OUTPUT_SECTION_NAME)
+ #define READONLY_EH_FRAME_SECTION_ASM_OP ".section\t.eh_frame,\"a\""
+ #endif
  
  #ifdef OBJECT_FORMAT_ELF
  
***************
*** 286,292 ****
--- 289,300 ----
  /* Stick a label at the beginning of the frame unwind info so we can register
     and deregister it with the exception handling library code.  */
  
+ #ifdef __PIC__
  asm (EH_FRAME_SECTION_ASM_OP);
+ #else
+ asm (READONLY_EH_FRAME_SECTION_ASM_OP);
+ #endif
+ 
  #ifdef INIT_SECTION_ASM_OP
  STATIC
  #endif
***************
*** 421,427 ****
--- 429,440 ----
     this would be the 'length' field in a real FDE.  */
  
  typedef unsigned int ui32 __attribute__ ((mode (SI)));
+ #ifdef __PIC__
  asm (EH_FRAME_SECTION_ASM_OP);
+ #else
+ asm (READONLY_EH_FRAME_SECTION_ASM_OP);
+ #endif
+ 
  STATIC ui32 __FRAME_END__[] = { 0 };
  #endif /* EH_FRAME_SECTION */
  
*** varasm.c.bak	Sat Sep 27 01:36:58 1997
--- varasm.c	Sun Oct  5 01:58:21 1997
***************
*** 410,416 ****
  {
    if (in_section != in_eh_frame)
      {
!       fprintf (asm_out_file, "%s\n", EH_FRAME_SECTION_ASM_OP);
        in_section = in_eh_frame;
      }
  } 
--- 410,419 ----
  {
    if (in_section != in_eh_frame)
      {
!       if (flag_pic)
! 	fprintf (asm_out_file, "%s\n", EH_FRAME_SECTION_ASM_OP);
!       else
! 	fprintf (asm_out_file, "%s\n", READONLY_EH_FRAME_SECTION_ASM_OP);
        in_section = in_eh_frame;
      }
  } 
*** output.h.bak	Sat Sep 27 01:30:36 1997
--- output.h	Sat Oct  4 23:54:39 1997
***************
*** 150,155 ****
--- 150,158 ----
  /* Tell assembler to switch to the section for the exception table.  */
  extern void exception_section		PROTO((void));
  
+ /* Tell assembler to switch to the section for the eh_frame info table. */
+ extern void eh_frame_section		PROTO((void));
+ 
  /* Create the rtl to represent a function, for a function definition.
     DECL is a FUNCTION_DECL node which describes which function.
     The rtl is stored into DECL.  */




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

end of thread, other threads:[~2007-05-30  5:42 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-10-08 15:38 .eh_frame section meissner
1997-10-08 21:19 ` Richard Henderson
1997-10-09  9:26   ` Ian Lance Taylor
1997-10-09  9:26     ` Jason Merrill
1997-10-10 17:21       ` Bruno Haible
1997-10-13  9:44         ` Joern Rennecke
1997-10-13 13:41           ` Richard Henderson
  -- strict thread matches above, loose matches on Subject: below --
2007-05-29 21:33 sfora dim
2007-05-29 23:13 ` Ian Lance Taylor
2007-05-30  7:41   ` sfora dim
1997-10-07 23:14 Bruno Haible
1997-10-07 23:14 ` Jason Merrill
1997-10-08  9:24   ` 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).