Re: alpha linux: R_ALPHA_LITERAL relocation overflow

[Nick Clifton]

Hi Mike,

> I submitted this to bugzilla last week, but I didn't know who to assign
> it to, and I wanted it to get more exposure.  If I'm posting this to the
> wrong place, I apologize:
No this is the right place for such questions, although you may find 
that posting to "address@hidden" is more effective as more 
people read that (parallel) list.  Anyway I was hoping that an Alpha 
expert would respond to your email, but nobody has stepped forward so 
instead you get me...
> I suspect there might be an overflow bug related to the R_ALPHA_LITERAL  
> relocation type in binutils, but I cannot be certain. 
If this is happening then it is happening in the assembler, which is the 
program that is choosing to generate the R_ALPHA_LITERAL reloc.  Have a 
look at the load_expressions() function in the binutils source file 
gas/config/tc-alpha.c.  You will need to search for 
BFD_RELOC_ALPHA_ELF_LITERAL as this is what the reloc is called there.
I suspect however that this might actually be a compiler problem, or 
even a user problem.  What I think might be happening is that the 
compiler is creating code that assumes that __divqu function will be 
within the 16-bit offset available to the R_ALPHA_LITERAL and telling 
the assembler to go ahead and generate the reloc.  Presumably this used 
to be OK when the libafs library was smaller, but now that it has grown 
this assumption is no longer true.
If this is correct then the next question to answer is whether the 
compiler is making this bogus assumption on its own, or if the user has 
told it (implicitly or explicitly) that such an assumption is valid.  I 
am thinking here of the gcc switches -msmall-data/-mlarge-data/ 
-msmall-text/-mlarge-text.  Maybe one of these needs to specified on the 
command line when compiling libafs.
Cheers
  Nick