This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug in .eh_frame_hdr processing


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]