left and right bit shift assembly operators

Indira wrote:

>Since no-one answered my previous post, I want to add more details 
>in regards to this cirtical problem that we're experiencing. Here's 
>the code snippet (Darwin for i86) that generates a problem (the last 
>line is the one that the compiler throws an error on stating that 
>"Relocation error. Absolute 0 assumed":

I am not familiar with the assembly language used in the code snippet 
you provided, but I can get an idea of what the line that throws up 
an error is trying to do. It seems to be setting the value of the 
symbol .L9 to the full size of the code snippet (in longwords), 
rounded up to a whole number.

The way this is being done looks rather fragile to me, but I can't 
see why the assembler should be finding a relocation error. It could 
be just a quirk of the assembler -- I have known them to get into 
difficulties when performing operations on relocatable values. If 
this is the case, it could be best to try to work round it.

I would suggest moving that last line:
.set .L9, ((.LA - x.L4) >> 2) + 9
to the beginning of the code (after the .text directive), changing it to:
.set .L9, (.LA - .) >> 2

If my understanding of the code is correct, this should achieve the 
same result, while making the code less liable to break if it were 
ever modified. There is then a possibility that the assembler could 
deal with the new form correctly. Who knows?

I am using the symbol "." to mean the current location counter - I 
don't know if that is right.

I am assuming the ".align 4" directive at the end means align to a 
longword boundary.

I am also assuming that there is an implicit ".align 4" at the start. 
If this is not the case, the new statement should be:
.set .L9, (.LA - . + 3) >> 2
instead.

If all else fails, you could always hack it by setting .L9 
temporarily to some arbitrary value and performing an assembly. Then 
examine the assembly listing, determine for yourself what the correct 
value should be, and set it to that instead. This is risky, but 
really no worse than what you have now.

Alec