reloc_name

[Simon Horman]

On Tue, Jan 15, 2008 at 05:53:19PM -0700, kevint wrote:
> This isn't a high priority issue- just something I am looking at in my 
> spare time.  I would appreciate any advice you can provide.
>
> I am looking through some of the kexec elf relocation code, and noticed 
> that reloc_name is only defined for x86_64.  I started writing this 
> function for the other architectures, but noticed that some of the other 
> architectures do not have contiguous r_type numbers (from include/elf.h). 
>  In the x86_64 reloc_name code, r_name is an array of strings with all of 
> the relocation names.  I can't (AFAIK) use a similar approach to 
> architectures with non-contiguous r_type numbers.
>
> My questions:
>
> Is it valuable to print out the relocation type as a string?  (I  
> personally find it helpful)
>
> If so, should the reloc_name function still reside in the kexec-elf- 
> rel-$ARCH.c file?  There are 81 IA64 relocations, which make the file  
> considerably longer.
>
> If not, should there be consistency between the different architectures 
> with regards to these types of error messages?  Should the X86_64 file 
> print out the r_type instead of the string?

I also noticed this when I applied your patch to pront out r_string on
x86_64. I'm all in favour of consistency. Though I think its ok
to have an r_type and an r_string version, where the latter can
be viewd as the aim for arhitectures that use the former.

As for bloating rel-$ARCH.c, I don't think that is much of
a problem if there is no existing header to use.

-- 
Horms