bug in .eh_frame_hdr processing

bug in .eh_frame_hdr processing

[Andrew Haley]

Java is broken on some platforms.  What happens is that exception
handlers in the runtime library fail to execute because the
personality routine in the CIE points to zero, rather than
DW.ref.__gcj_personality_v0.

This seems to be a consequence of the optimization in elf-eh-frame.c.
When generating relocateable output, we really shouldn't adjust the
offset to the personality routine, as it hasn't been relocated yet.

Alternatively, perhaps we shouldn't do this optimization at all when
generating relocateable output, but instead postpone it until final
link.

Andrew.

2003-02-22  Andrew Haley  <aph@redhat.com>
	
	* elf-eh-frame.c (_bfd_elf_write_section_eh_frame): Don't adjust
	personality offset if we're generating relocateable output.
 
Index: elf-eh-frame.c
===================================================================
RCS file: /cvs/src/src/bfd/elf-eh-frame.c,v
retrieving revision 1.22
diff -u -6 -w -r1.22 elf-eh-frame.c
--- elf-eh-frame.c	6 Feb 2003 23:01:04 -0000	1.22
+++ elf-eh-frame.c	22 Feb 2003 20:05:52 -0000
@@ -940,20 +940,23 @@
 		    if ((per_encoding & 0xf0) == DW_EH_PE_aligned)
 		      buf = (contents
 			     + ((buf - contents + per_width - 1)
 				& ~((bfd_size_type) per_width - 1)));
 		    if (action & 4)
 		      {
+			if (!info->relocateable)
+			  {
 			bfd_vma value;
 
 			value = read_value (abfd, buf, per_width,
 					    get_DW_EH_PE_signed
 					    (per_encoding));
 			value += (sec_info->entry[i].offset
 				  - sec_info->entry[i].new_offset);
 			write_value (abfd, buf, value, per_width);
+			  }
 			action &= ~4;
 		      }
 		    buf += per_width;
 		    break;
 		  case 'R':
 		    if (action & 1)

Re: bug in .eh_frame_hdr processing

[Richard Henderson]

On Sat, Feb 22, 2003 at 08:11:54PM +0000, Andrew Haley wrote:
> Alternatively, perhaps we shouldn't do this optimization at all when
> generating relocateable output, but instead postpone it until final
> link.

I'd prefer this.


r~

Re: bug in .eh_frame_hdr processing

[Andrew Haley]

Richard Henderson writes:
 > On Sat, Feb 22, 2003 at 08:11:54PM +0000, Andrew Haley wrote:
 > > Alternatively, perhaps we shouldn't do this optimization at all when
 > > generating relocateable output, but instead postpone it until final
 > > link.
 > 
 > I'd prefer this.

Me too.  It's simpler, and safer.

Andrew.

Re: bug in .eh_frame_hdr processing

[Alan Modra]

On Sun, Feb 23, 2003 at 11:01:01AM +0000, Andrew Haley wrote:
> Richard Henderson writes:
>  > On Sat, Feb 22, 2003 at 08:11:54PM +0000, Andrew Haley wrote:
>  > > Alternatively, perhaps we shouldn't do this optimization at all when
>  > > generating relocateable output, but instead postpone it until final
>  > > link.
>  > 
>  > I'd prefer this.
> 
> Me too.  It's simpler, and safer.

Yes, given that this is at least the second ld -r problem found in the
eh_frame editing code, I think I made a mistake in enabling the
optimization for ld -r.  It wouldn't hurt to commit your fix though.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: bug in .eh_frame_hdr processing

[Andrew Haley]

Alan Modra writes:
 > On Sun, Feb 23, 2003 at 11:01:01AM +0000, Andrew Haley wrote:
 > > Richard Henderson writes:
 > >  > On Sat, Feb 22, 2003 at 08:11:54PM +0000, Andrew Haley wrote:
 > >  > > Alternatively, perhaps we shouldn't do this optimization at all when
 > >  > > generating relocateable output, but instead postpone it until final
 > >  > > link.
 > >  > 
 > >  > I'd prefer this.
 > > 
 > > Me too.  It's simpler, and safer.
 > 
 > Yes, given that this is at least the second ld -r problem found in the
 > eh_frame editing code, I think I made a mistake in enabling the
 > optimization for ld -r.  It wouldn't hurt to commit your fix though.

Jakub sent me this patch in email:

2003-02-27   Jakub Jelinek <jakub@redhat.com>
             Andrew Haley  <aph@redhat.com>

	* elflink.h (elf_bfd_discard_info): Don't process eh frames if
	output is relocateable.

Index: elflink.h
===================================================================
RCS file: /cvs/src/src/bfd/elflink.h,v
retrieving revision 1.206
diff -c -2 -p -r1.206 elflink.h
*** elflink.h   17 Feb 2003 18:24:40 -0000      1.206
--- elflink.h   27 Feb 2003 17:58:30 -0000
*************** elf_bfd_discard_info (output_bfd, info)
*** 8329,8335 ****
  
        eh = bfd_get_section_by_name (abfd, ".eh_frame");
!       if (eh != NULL
!         && (eh->_raw_size == 0
!             || bfd_is_abs_section (eh->output_section)))
        eh = NULL;
  
--- 8329,8336 ----
  
        eh = bfd_get_section_by_name (abfd, ".eh_frame");
!       if (info->relocateable
!         || (eh != NULL
!             && (eh->_raw_size == 0
!                 || bfd_is_abs_section (eh->output_section))))
        eh = NULL;
  
*************** elf_bfd_discard_info (output_bfd, info)
*** 8432,8435 ****
--- 8433,8437 ----
  
    if (info->eh_frame_hdr
+       && !info->relocateable
        && _bfd_elf_discard_section_eh_frame_hdr (output_bfd, info))
      ret = TRUE;

Re: bug in .eh_frame_hdr processing

[Andrew Haley]

Andrew Haley writes:
 > Alan Modra writes:
 >  > On Sun, Feb 23, 2003 at 11:01:01AM +0000, Andrew Haley wrote:
 >  > > Richard Henderson writes:
 >  > >  > On Sat, Feb 22, 2003 at 08:11:54PM +0000, Andrew Haley wrote:
 >  > >  > > Alternatively, perhaps we shouldn't do this optimization at all when
 >  > >  > > generating relocateable output, but instead postpone it until final
 >  > >  > > link.
 >  > >  > 
 >  > >  > I'd prefer this.
 >  > > 
 >  > > Me too.  It's simpler, and safer.
 >  > 
 >  > Yes, given that this is at least the second ld -r problem found in the
 >  > eh_frame editing code, I think I made a mistake in enabling the
 >  > optimization for ld -r.  It wouldn't hurt to commit your fix though.
 > 
 > Jakub sent me this patch in email:
 > 
 > 2003-02-27   Jakub Jelinek <jakub@redhat.com>
 >              Andrew Haley  <aph@redhat.com>
 > 
 > 	* elflink.h (elf_bfd_discard_info): Don't process eh frames if
 > 	output is relocateable.

Well, shall I apply it then?

Andrew.

Re: bug in .eh_frame_hdr processing

[Richard Henderson]

On Wed, Mar 05, 2003 at 05:35:44PM +0000, Andrew Haley wrote:
>  > 	* elflink.h (elf_bfd_discard_info): Don't process eh frames if
>  > 	output is relocateable.
> 
> Well, shall I apply it then?

Yes please.


r~

Re: bug in .eh_frame_hdr processing

[Alan Modra]

On Thu, Feb 27, 2003 at 06:07:59PM +0000, Andrew Haley wrote:
> Alan Modra writes:
>  > On Sun, Feb 23, 2003 at 11:01:01AM +0000, Andrew Haley wrote:
>  > > Richard Henderson writes:
>  > >  > On Sat, Feb 22, 2003 at 08:11:54PM +0000, Andrew Haley wrote:
>  > >  > > Alternatively, perhaps we shouldn't do this optimization at all when
>  > >  > > generating relocateable output, but instead postpone it until final
>  > >  > > link.
>  > >  > 
>  > >  > I'd prefer this.
>  > > 
>  > > Me too.  It's simpler, and safer.
>  > 
>  > Yes, given that this is at least the second ld -r problem found in the
>  > eh_frame editing code, I think I made a mistake in enabling the
>  > optimization for ld -r.  It wouldn't hurt to commit your fix though.
> 
> Jakub sent me this patch in email:
> 
> 2003-02-27   Jakub Jelinek <jakub@redhat.com>
>              Andrew Haley  <aph@redhat.com>
> 
> 	* elflink.h (elf_bfd_discard_info): Don't process eh frames if
> 	output is relocateable.

At the time this patch went in, I'd forgotten why I enabled eh_frame
optimization during ld -r.  Of course, the problem has raised its ugly
head again.

The problem being that linux kernel modules written in C++ need to have
some sort of eh_frame optimization pass to remove info related to
removed linkonce sections.  Otherwise, you end up with relocations
against the zero index symbol and modutils segfaults.  Worse, even if
modutils is hacked to get around the segfault, I think the unwinder
would have problems interpreting eh_frame.

I see two ways to fix this problem:
a) Implement a new option, eg. -z eh_frame_optimize, that runs eh_frame
   optimization for ld -r.
b) Remove optimizations in elf-eh-frame.c that are unsafe for ld -r, and
   always run eh_frame optimization.

(a) is easy, and justified on the grounds that no further linking will
be done on a linux kernel module.  ie. it's a ld -r that is "final" in
some sense.  (b) is harder, so I'll do (a), unless Jakub reckons he
knows what should be done for (b).

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: bug in .eh_frame_hdr processing

[Jakub Jelinek]

On Tue, Sep 09, 2003 at 11:55:43AM +0930, Alan Modra wrote:
> At the time this patch went in, I'd forgotten why I enabled eh_frame
> optimization during ld -r.  Of course, the problem has raised its ugly
> head again.
> 
> The problem being that linux kernel modules written in C++ need to have
> some sort of eh_frame optimization pass to remove info related to
> removed linkonce sections.  Otherwise, you end up with relocations
> against the zero index symbol and modutils segfaults.  Worse, even if
> modutils is hacked to get around the segfault, I think the unwinder
> would have problems interpreting eh_frame.
> 
> I see two ways to fix this problem:
> a) Implement a new option, eg. -z eh_frame_optimize, that runs eh_frame
>    optimization for ld -r.
> b) Remove optimizations in elf-eh-frame.c that are unsafe for ld -r, and
>    always run eh_frame optimization.
> 
> (a) is easy, and justified on the grounds that no further linking will
> be done on a linux kernel module.  ie. it's a ld -r that is "final" in
> some sense.  (b) is harder, so I'll do (a), unless Jakub reckons he
> knows what should be done for (b).

Part of elf-eh-frame.c relies on the relocation processing done in
*relocate_section. With ld -r such relocation processing doesn't happen,
so (a) is not that easy either.
What IMHO can be done for (a) easily is to turn FDEs against removed
linkonce sections into dummy CIEs nobody will reference.
This means: changing all relocations against addresses within the FDE
into R_*_NONE and setting FDE's payload to
.long 0; .byte 1, 0, 1, 0x7c, 0 and bzero the rest.
This could be done with ld -r always, as elf-eh-frame.c should nuke
unused CIEs during final link.

	Jakub