>Hello,
>
>I am using sgicc to run an application with some hand-coded assembly
>functions. SGIcc ver is 0.01.0-13, building the app on my Itanium system
>running Linux kernel 2.4.1-010131-8.
>
>Problem: segmentation Fault (Core dumped)
>I use the alloc statement in the handcoded assembly to allocate a stack
>frame;
> alloc r36=ar.pfs,0,6,4,0
>
>This alloc statement is from code generated by SGIcc at the start of a
>function called with foo(void* a, void* b, void* c, void*d), which itself
>calls another function with 3 args - foo2(void* a, int b, int c).
>
>When run, there occurs a Seg fault at the alloc statement in the assembly
>function. From the disassembly, this statement looks like this:
> alloc r36=ar.pfs,10,6,0
>
>Question: Why does the disassembly have a different stack allocation pattern
>than the source assembly. Secondly, any clues about the Seg fault at this
>statement? (this is the first statement in the assembly for foo()
>From the Intel documentation, you find that that the assembler notation
for the alloc instruction has one more operand than the actual machine
instruction. These sentences from the alloc description are relevant:
The size of the local region (sol) is given by i + l.
There is no real distinction between inputs and locals.
They are given as separate operands in the instruction
only as a hint to the assembler about how the local
registers are to be used.
So once you assemble the instruction, the values of i and l are lost
You only have the sum. A dissassembler cannot reconstruct the original
instruction exactly.
However, in my opinion, disassembing the instruction with one less
argument seems bogus to me as it is not clear, at least to me,
what the arguments are. I think it would have been better
to generate the original form, but always leaving one of i or l zero.
I may be wrong, but I doubt the assembler will accept the form
generated by the dissassembler.
>Apprecaite any help.
>Thanks,
>Prasad
As to your segmentation fault, I unfortunately have no clues for you.
Ken
|