RE: SH relocation differences in older versions of the binutils

[Jeff Baker <jbaker at qnx dot com>]

These are the collisions:

33 (R_SH_SWITCH8) moved to 24 (UNUSED) replaced by R_SH_DIR16
34 (R_SH_GNU_VTINHERIT) moved to 22 (UNUSED) replaced by R_SH_DIR8
35 (R_SH_GNU_VTENTRY) moved to 23 (UNUSED) replaced by R_SH_DIR8UL
36 (R_SH_LOOP_START) moved to 10 (UNUSED) replaced by R_SH_DIR8UW
37 (R_SH_LOOP_END) moved to 11 (UNUSED) replaced by R_SH_DIR8U

Obviously if I see 10, 11, 22, 23 or 24 I can assume the .o was generated
after the reloc changes.  The issue is what to do if I see 33->37.  Is there
anything I can do to detect if I need to change the number to maintain
compatibility (or generate some sort of sensible error message)?

Ultimately what we would prefer is a .comment entry (or something similar)
that specifically states what versions of the tools were used.  What method
for storing this information is likely to be accepted as a patch?

> -----Original Message-----
> From: DJ Delorie [mailto:dj@redhat.com]
> Sent: Tuesday, January 06, 2004 3:53 PM
> To: jbaker@qnx.com
> Cc: binutils@sources.redhat.com
> Subject: Re: SH relocation differences in older versions of the binutils
> 
> 
> > For example: If I send you some random .o that contains a reloc number
> 0x24
> > can you tell me if it's supposed to be an R_SH_LOOP_START or an
> R_SH_DIR8UW
> > just by examining the binary?
> 
> Well, R_SH_LOOP_START should point to the loop opcode (or near it), if
> you want to disassemble it.  I don't expect that to be reliable,
> though.