[fpc-devel] question about parameter loading code
Dear sirs, When trying to generate code debuggable by GDB, I meet a problem: * it seems mips C code will expect a frame pointer = sp after stack adjustment * but in cpupara.pas, when we create para info, we don't know yet the whole stack size, thus the reference offset cannot be set correctly In current code, I use move fp, sp addiu sp,sp,-LocalSize ... and use the frame pointer fp as reference base, so the offset for callee can be the same as the caller side. In MIPS ABI, the parameter area for callee functions is at the bottom of caller function's stack, so the offsets are decided only by parameters when use fp(or the caller's sp, or the sp upon function entry) as the base. C code is something like: addiu sp,sp,-LocalSize swfp, 4(sp) move fp, sp in this way, I don't know how to generate parameter references since no usable base register to get fixed offset for parameters in create_paraloc_info_intern. Could you give some hints? Best Regards ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Scalar value is accepted as an argument for an openarray parameter
-Original Message- From: Marc Weustink Sent: Friday, June 08, 2012 9:08 To: FPC developers' list Subject: Re: [fpc-devel] Scalar value is accepted as an argument for an openarray parameter On 8-6-2012 8:18, Alexander Klenin wrote: The following code compiles both with : procedure F(const A: array of ShortInt); begin end; begin F(1); end. I think this is a bug in FPC, but if not -- it should be documented here: http://freepascal.org/docs-html/ref/refsu59.html#x157-16700014.4.5 I am willing to file an issue one way or another. Unfortunately Delphi (6) accepts this too. It took me some time at work Delphi XE2 does not ;) Bye, Skybuck :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] strange behavior of mips stabs
for a function like this:
int i(int b)
{
int i1,i2,i3;
return i1 + i2;
}
in x86, compile with gcc -fno-pic -fomit-frame-pointer -gstabs -O0 -S
the output is:
Lscope1:
.stabs i:F(0,1),36,0,0,i
.stabs b:p(0,1),160,0,0,-20
.globl i
.type i, @function
i:
.stabn 68,0,10,.LM5-.LFBB2
.LM5:
.LFBB2:
.LFB1:
.cfi_startproc
movl%edi, -20(%rsp)
.stabn 68,0,12,.LM6-.LFBB2
.LM6:
movl-8(%rsp), %eax
movl-4(%rsp), %edx
leal(%rdx,%rax), %eax
.stabn 68,0,13,.LM7-.LFBB2
.LM7:
ret
.cfi_endproc
.LFE1:
.size i, .-i
.stabs i1:(0,1),128,0,0,-4
.stabs i2:(0,1),128,0,0,-8
.stabs i3:(0,1),128,0,0,-12
.stabn 192,0,0,.LFBB2-.LFBB2
.stabn 224,0,0,.Lscope2-.LFBB2
Everything works as expect:
the offsets for both parameters and locals are negative, no matter in
stabs directive or in the assembly code. And the offset value in stabs
equals to the one in the code.
But for mips, mipsel-linux-gcc -fno-pic -fomit-frame-pointer -gstabs -O0
-S output is:
scope1:
.align 2
.stabs i:F(0,1),36,0,0,i
.stabs b:p(0,1),160,0,0,24
.globl i
.enti
.type i, @function
i:
.stabn 68,0,10,$LM5
$LM5:
$LFBB2:
.setnomips16
.frame $sp,24,$31 # vars= 16, regs= 0/0, args= 0, gp= 8
.mask 0x,0
.fmask 0x,0
.setnoreorder
.setnomacro
addiu $sp,$sp,-24
.cprestore 0
sw $4,24($sp)
.stabn 68,0,12,$LM6
$LM6:
lw $3,16($sp)
lw $2,12($sp)
nop
addu$2,$3,$2
.stabn 68,0,13,$LM7
$LM7:
addiu $sp,$sp,24
j $31
nop
.setmacro
.setreorder
.endi
.stabs i1:(0,1),128,0,0,-8
.stabs i2:(0,1),128,0,0,-12
The local variable offsets in stabs are negative, but in the code they are
positive. For my understanding of fpc logic, they should both generated
from loc.reference.offset or something similiar, they cannot be different.
If I am not making mistake, we have to special case some code to make
debugging work.
Am I wrong?
Regards
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strange behavior of mips stabs
After looking into the gcc code, it is really so uncommon:( Lots of pain
to get full support.
gcc-4.4.6/gcc/config/mips/mips.c
line 7484:
/* The MIPS debug format wants all automatic variables and arguments
to be in terms of the virtual frame pointer (stack pointer before
any adjustment in the function), while the MIPS 3.0 linker wants
the frame pointer to be the stack pointer after the initial
adjustment. So, we do the adjustment here. The arg pointer (which
is eliminated) points to the virtual frame pointer, while the frame
pointer (which may be eliminated) points to the stack pointer after
the initial adjustments. */
HOST_WIDE_INT
mips_debugger_offset (rtx addr, HOST_WIDE_INT offset)
{
rtx offset2 = const0_rtx;
rtx reg = eliminate_constant_term (addr, offset2);
if (offset == 0)
offset = INTVAL (offset2);
if (reg == stack_pointer_rtx
|| reg == frame_pointer_rtx
|| reg == hard_frame_pointer_rtx)
{
offset -= cfun-machine-frame.total_size; // here it is
if (reg == hard_frame_pointer_rtx)
offset += cfun-machine-frame.hard_frame_pointer_offset;
}
for a function like this:
int i(int b)
{
int i1,i2,i3;
return i1 + i2;
}
in x86, compile with gcc -fno-pic -fomit-frame-pointer -gstabs -O0 -S
the output is:
Lscope1:
.stabs i:F(0,1),36,0,0,i
.stabs b:p(0,1),160,0,0,-20
.globl i
.type i, @function
i:
.stabn 68,0,10,.LM5-.LFBB2
.LM5:
.LFBB2:
.LFB1:
.cfi_startproc
movl%edi, -20(%rsp)
.stabn 68,0,12,.LM6-.LFBB2
.LM6:
movl-8(%rsp), %eax
movl-4(%rsp), %edx
leal(%rdx,%rax), %eax
.stabn 68,0,13,.LM7-.LFBB2
.LM7:
ret
.cfi_endproc
.LFE1:
.size i, .-i
.stabs i1:(0,1),128,0,0,-4
.stabs i2:(0,1),128,0,0,-8
.stabs i3:(0,1),128,0,0,-12
.stabn 192,0,0,.LFBB2-.LFBB2
.stabn 224,0,0,.Lscope2-.LFBB2
Everything works as expect:
the offsets for both parameters and locals are negative, no matter in
stabs directive or in the assembly code. And the offset value in stabs
equals to the one in the code.
But for mips, mipsel-linux-gcc -fno-pic -fomit-frame-pointer -gstabs -O0
-S output is:
scope1:
.align 2
.stabs i:F(0,1),36,0,0,i
.stabs b:p(0,1),160,0,0,24
.globl i
.enti
.type i, @function
i:
.stabn 68,0,10,$LM5
$LM5:
$LFBB2:
.setnomips16
.frame $sp,24,$31 # vars= 16, regs= 0/0, args= 0,
gp= 8
.mask 0x,0
.fmask 0x,0
.setnoreorder
.setnomacro
addiu $sp,$sp,-24
.cprestore 0
sw $4,24($sp)
.stabn 68,0,12,$LM6
$LM6:
lw $3,16($sp)
lw $2,12($sp)
nop
addu$2,$3,$2
.stabn 68,0,13,$LM7
$LM7:
addiu $sp,$sp,24
j $31
nop
.setmacro
.setreorder
.endi
.stabs i1:(0,1),128,0,0,-8
.stabs i2:(0,1),128,0,0,-12
The local variable offsets in stabs are negative, but in the code they are
positive. For my understanding of fpc logic, they should both generated
from loc.reference.offset or something similiar, they cannot be different.
If I am not making mistake, we have to special case some code to make
debugging work.
Am I wrong?
Regards
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] question about parameter loading code
Dear sirs, C code is something like: addiu sp,sp,-LocalSize swfp, 4(sp) move fp, sp in this way, I don't know how to generate parameter references since no usable base register to get fixed offset for parameters in create_paraloc_info_intern. Can we use a special virtual register as base here? Then after the stack size is known, we could replace the base/offset with real fp and offset. 1, At what time can the stack size of a procedure be known/fix? 2, Is there any other access to the para array before gen_load_para_value? Also for the debug stabs generation, we could mark the symbol need to get special treating, and handle it when writing it out. Could you give some hints? Best Regards ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Scalar value is accepted as an argument for an openarray parameter
On 10.06.2012 00:22, Skybuck Flying wrote:
-Original Message- From: Marc Weustink
Sent: Friday, June 08, 2012 9:08
To: FPC developers' list
Subject: Re: [fpc-devel] Scalar value is accepted as an argument for an
openarray parameter
On 8-6-2012 8:18, Alexander Klenin wrote:
The following code compiles both with :
procedure F(const A: array of ShortInt); begin end;
begin F(1); end.
I think this is a bug in FPC, but if not -- it should be documented here:
http://freepascal.org/docs-html/ref/refsu59.html#x157-16700014.4.5
I am willing to file an issue one way or another.
Unfortunately Delphi (6) accepts this too. It took me some time at work
Delphi XE2 does not ;)
Delphi XE does not accept constants either, but scalar variables. So the
following compiles:
=== source begin ===
program openarrayscalar;
{$apptype console}
procedure Test(aArgs: array of LongInt);
var
i: LongInt;
begin
for i in aArgs do
Writeln(i);
end;
var
z: LongInt;
begin
z := 42;
Test(z);
Readln;
end.
=== source end ===
The Delphi help also mentions this here:
http://docwiki.embarcadero.com/RADStudio/en/Parameters_%28Delphi%29#Open_Array_Parameters
=== qoute begin ===
Instead of an array, you can pass a variable of the open array
parameter's base type. It will be treated as an array of length 1.
=== qoute end ===
Constant values and untyped constants can indeed not be used as argument
for open array parameters, but typed constants can.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] question about parameter loading code
Am 10.06.2012 08:15, schrieb Fuxin Zhang: Dear sirs, When trying to generate code debuggable by GDB, I meet a problem: * it seems mips C code will expect a frame pointer = sp after stack adjustment * but in cpupara.pas, when we create para info, we don't know yet the whole stack size, thus the reference offset cannot be set correctly This is exactly the point where I'am already stuck with MIPS for several days/weeks. I'am still no sure what's the best solution ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] question about parameter loading code
10.06.2012 20:26, Florian Klämpfl пишет: Am 10.06.2012 08:15, schrieb Fuxin Zhang: Dear sirs, When trying to generate code debuggable by GDB, I meet a problem: * it seems mips C code will expect a frame pointer = sp after stack adjustment * but in cpupara.pas, when we create para info, we don't know yet the whole stack size, thus the reference offset cannot be set correctly This is exactly the point where I'am already stuck with MIPS for several days/weeks. I'am still no sure what's the best solution ... As far as I can understand, basically the same problem stands in the way of implementing compliant stack frames for x86_64-win64. I was thinking about a having a virtual framepointer register. We'll need to: - keep a list of all assembler instructions that reference this virtual FP register - after final frame size becomes known, fixup these instructions to reference a real FP with adjusted offset. Or maybe not keep a separate list of instructions, but instead just iterate the entire procedure asmlist (because about every second instruction is subject to fixup). Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] question about parameter loading code
On 10 Jun 2012, at 18:50, Sergei Gorelkin wrote: - after final frame size becomes known, fixup these instructions to reference a real FP with adjusted offset. Or maybe not keep a separate list of instructions, but instead just iterate the entire procedure asmlist (because about every second instruction is subject to fixup). The problem on MIPS (and other RISC architectures), is that you may need more than one instruction to access such a memory location if the final offset is larger than a certain limit. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] question about parameter loading code
Am 10.06.2012 19:18, schrieb Jonas Maebe: On 10 Jun 2012, at 18:50, Sergei Gorelkin wrote: - after final frame size becomes known, fixup these instructions to reference a real FP with adjusted offset. Or maybe not keep a separate list of instructions, but instead just iterate the entire procedure asmlist (because about every second instruction is subject to fixup). The problem on MIPS (and other RISC architectures), is that you may need more than one instruction to access such a memory location if the final offset is larger than a certain limit. This is why I'am working on being able to generate code more than once for procedures if needed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
