I checked that the assembler does not accept three parameters (instead of
four) for the alloc statement. we still need the distinct i,l,o,r fields.
But surprisingly, the size of the local frame (i+l) from the disassembler is
10, while the assembler alloc statement specifies only 6. Also, I don;t
understand the o field in the disassembler - 6, when I have just 4 o/p in
the assembler. Compare the following:
Assembler: alloc r36=ar.pfs,0,6,4,0
Disassembler: alloc r36=ar.pfs,10,6,0
Thanks,
Prasad
> -----Original Message-----
> From: lesniak@xxxxxxxxxxxxxxxxxxxxx [SMTP:lesniak@xxxxxxxxxxxxxxxxxxxxx]
> Sent: Monday, June 25, 2001 6:37 AM
> To: 'pro64-support@xxxxxxxxxxx'; Kakulavarapu, Prasad
> Subject: Re: Stack Frame allocation
>
> >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
|