public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* RFC on removing R_PARISC_DIR21L in DSO for hppa?
@ 2004-06-27 15:39 Carlos O'Donell
  2004-06-27 23:45 ` Alan Modra
  0 siblings, 1 reply; 3+ messages in thread
From: Carlos O'Donell @ 2004-06-27 15:39 UTC (permalink / raw)
  To: binutils


I'm seeing that on occassion a number of DSO's have ended up with
R_PARISC_DIR21L relocations, these relocations are not handled by the
dyanmic loader in glibc (I'm not sure how to handle them to tell you the
truth). There is code here that is '#ifdef 0' with a comment indicating
that it is for debugging purposes.

I assumed that DIR21L and such relocations would endup as DIR32
relocations, those being the only relocs I've ever seen in after a final
link. Would it be valid to warn again when DIR21L relocations are about
to make it into the final link? Or am I missing the point here, do they
finally get turned into DIR32 and halting the link in
elf32_hppa_check_relocs() is not the correct thing to do?

Cheers,
Carlos

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

* Re: RFC on removing R_PARISC_DIR21L in DSO for hppa?
  2004-06-27 15:39 RFC on removing R_PARISC_DIR21L in DSO for hppa? Carlos O'Donell
@ 2004-06-27 23:45 ` Alan Modra
  2004-06-28 17:54   ` Carlos O'Donell
  0 siblings, 1 reply; 3+ messages in thread
From: Alan Modra @ 2004-06-27 23:45 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: binutils

On Sun, Jun 27, 2004 at 11:39:36AM -0400, Carlos O'Donell wrote:
> Would it be valid to warn again when DIR21L relocations are about
> to make it into the final link?

Yes.  Since glibc's ld.so doesn't handle them, you could merge the
DIR17F thru DIR21L cases with the DPREL ones immediately above.  ie.
turn the warning into a hard error.

I think when I wrote that code, I was distinguishing relocs that could
be handled by ld.so from those that can't (DPREL are only valid in the
main app).  It's a rather pedantic distinction when ld.so doesn't
provide support though!

I'm not sure why the warning was turned off for DIR17F .. DIR21L.  It
was probably an over-enthusiastic change when disabling other warnings.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

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

* Re: RFC on removing R_PARISC_DIR21L in DSO for hppa?
  2004-06-27 23:45 ` Alan Modra
@ 2004-06-28 17:54   ` Carlos O'Donell
  0 siblings, 0 replies; 3+ messages in thread
From: Carlos O'Donell @ 2004-06-28 17:54 UTC (permalink / raw)
  To: Alan Modra; +Cc: binutils

On Mon, Jun 28, 2004 at 09:15:02AM +0930, Alan Modra wrote:
> On Sun, Jun 27, 2004 at 11:39:36AM -0400, Carlos O'Donell wrote:
> > Would it be valid to warn again when DIR21L relocations are about
> > to make it into the final link?
> 
> Yes.  Since glibc's ld.so doesn't handle them, you could merge the
> DIR17F thru DIR21L cases with the DPREL ones immediately above.  ie.
> turn the warning into a hard error.
> 
> I think when I wrote that code, I was distinguishing relocs that could
> be handled by ld.so from those that can't (DPREL are only valid in the
> main app).  It's a rather pedantic distinction when ld.so doesn't
> provide support though!
> 
> I'm not sure why the warning was turned off for DIR17F .. DIR21L.  It
> was probably an over-enthusiastic change when disabling other warnings.

That's what I thought, I'll stew my patch a bit more to make sure I've
got the hard error in the right place, then I'll submit a patch.

Thanks Alan,

Cheers,
Carlos.

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

end of thread, other threads:[~2004-06-28 17:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-27 15:39 RFC on removing R_PARISC_DIR21L in DSO for hppa? Carlos O'Donell
2004-06-27 23:45 ` Alan Modra
2004-06-28 17:54   ` Carlos O'Donell

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