[fpc-pascal] backtrace code in fpc

[Matias Vara]

Hello everyone, I am trying to port the code for backtrace, e.g.,
GetLineInfo(), to my freepascal kernel in order to print a backtrace when
an exception happens. The drawback now is that I am not sure where the
source is. I think it is the unit lnfodwrf.pp however I am not sure. From
the code, it seems that this unit is opening the executable to get the
debug section, is this correct? is it not getting the name of the symbols
from memory? In my case, the debug symbols must be taken from memory since
there is no disk access.

Regards, Matias.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] backtrace code in fpc

[Matias Vara]

Hello Charlie and thanks for the comments. I ended up by implementing my
own Infodwrf unit.

Matias

On 18 Jul 2017 11:48 p.m., "Karoly Balogh (Charlie/SGR)" <
char...@scenergy.dfmk.hu> wrote:

Hi,

On Mon, 17 Jul 2017, Matias Vara wrote:

> Hello everyone, I am trying to port the code for backtrace, e.g.,
> GetLineInfo(), to my freepascal kernel in order to print a backtrace
> when an exception happens.

Slightly off topic, but make sure when you copy code from (or even study
the source of) the RTL, that your resulting code is license compatible.

> The drawback now is that I am not sure where the source is. I think it
> is the unit lnfodwrf.pp however I am not sure.

The backtrace/stack traversal code itself is in system unit, see
FPC_PushExceptObject and surrounding code. To print the frames collected
there, the system unit will just use BackTraceStrFunc as implemented by
various debuginfo units to print lineinfo strings based on information by
the different debug/symbol formats.

You just have to implement your own debug info parser and custom
BackTraceStrFunc, then the RTL should handle the rest. You can check the
various locations where BackTraceStrFunc is called in system unit for
further reference.

> From the code, it seems that this unit is opening the executable to get
> the debug section, is this correct? is it not getting the name of the
> symbols from memory? In my case, the debug symbols must be taken from
> memory since there is no disk access.

The lnfodwrf unit just gets the symbol name for a given address, stored in
DWARF debug info sections in an executable, and injects it's own
BackTraceStrFunc in the RTL to return that.. The same with lineinfo unit
for STABS debug info format, actually. Opening a file and loading it is
not a requirement, as long as your tables are in the memory anyway. But
normally these are not loaded by the executable loader of OSes, hence
these units will load/parse them.

If they're in memory in your case already, you can just skip the loading,
and implement your own customized version of lnfodwrf unit, etc.

BackTraceStrFunc is the key really, as it's quite universal. And the
default implementation is quite simple, see SysBackTraceStr.

Hope this was helpful,
--
Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] backtrace code in fpc

[Matias Vara]

Hello,

I am not sure why my executable does not contains a .debug_aranges section.
It contains .debug_line and .debug_info. Am I missing some linker flags?

Thanks, Matias.

2017-07-19 0:05 GMT+01:00 Matias Vara <matiasev...@gmail.com>:

> Hello Charlie and thanks for the comments. I ended up by implementing my
> own Infodwrf unit.
>
> Matias
>
>
> On 18 Jul 2017 11:48 p.m., "Karoly Balogh (Charlie/SGR)" <
> char...@scenergy.dfmk.hu> wrote:
>
> Hi,
>
> On Mon, 17 Jul 2017, Matias Vara wrote:
>
> > Hello everyone, I am trying to port the code for backtrace, e.g.,
> > GetLineInfo(), to my freepascal kernel in order to print a backtrace
> > when an exception happens.
>
> Slightly off topic, but make sure when you copy code from (or even study
> the source of) the RTL, that your resulting code is license compatible.
>
> > The drawback now is that I am not sure where the source is. I think it
> > is the unit lnfodwrf.pp however I am not sure.
>
> The backtrace/stack traversal code itself is in system unit, see
> FPC_PushExceptObject and surrounding code. To print the frames collected
> there, the system unit will just use BackTraceStrFunc as implemented by
> various debuginfo units to print lineinfo strings based on information by
> the different debug/symbol formats.
>
> You just have to implement your own debug info parser and custom
> BackTraceStrFunc, then the RTL should handle the rest. You can check the
> various locations where BackTraceStrFunc is called in system unit for
> further reference.
>
> > From the code, it seems that this unit is opening the executable to get
> > the debug section, is this correct? is it not getting the name of the
> > symbols from memory? In my case, the debug symbols must be taken from
> > memory since there is no disk access.
>
> The lnfodwrf unit just gets the symbol name for a given address, stored in
> DWARF debug info sections in an executable, and injects it's own
> BackTraceStrFunc in the RTL to return that.. The same with lineinfo unit
> for STABS debug info format, actually. Opening a file and loading it is
> not a requirement, as long as your tables are in the memory anyway. But
> normally these are not loaded by the executable loader of OSes, hence
> these units will load/parse them.
>
> If they're in memory in your case already, you can just skip the loading,
> and implement your own customized version of lnfodwrf unit, etc.
>
> BackTraceStrFunc is the key really, as it's quite universal. And the
> default implementation is quite simple, see SysBackTraceStr.
>
> Hope this was helpful,
> --
> Charlie
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
>
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] backtrace code in fpc

[Matias Vara]

Hello Florian,

2017-07-22 13:49 GMT+01:00 Florian Klämpfl <flor...@freepascal.org>:

> Am 22.07.2017 um 14:47 schrieb Matias Vara:
> > Hello,
> >
> > I am not sure why my executable does not contains a .debug_aranges
> section. It contains .debug_line
> > and .debug_info. Am I missing some linker flags?
> >
>
> Maybe not included by the linker script?
>
>
Maybe, I am not sure. The map file does show a .debug_aranges section
either. Also I cannot find any information about .debug_arranges section in
the generated .s. The section is included by the link script:

.debug_aranges BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_aranges) }


Matias




> __
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] cpu_relax() in freepascal

[Matias Vara]

Hello,

I think it would be better if I put my question in context. In order to
tell the processor that we are in a loop, the pause instruction could be
used (also I think the "rep nop" produces the same opcode). This tells the
processor that we are in a loop so it improves the access to the cache and
the branching mechanism. My question is if the compiler is doing any
improvement of this kind in a loop or I should write my own "pause"
procedure/macro. For more info
https://software.intel.com/en-us/articles/benefitting-power-and-performance-sleep-loops

Cheers!

2017-10-29 16:59 GMT+01:00 Matias Vara <matiasev...@gmail.com>:

> Hello everyone,
>
> I want to implement the cpu_relax() function in order to use it inside
> loops. However before, I would like to know if the fpc compiler is doing an
> optimization of this kind.
>
> Kinds regards, Matias.
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] cpu_relax() in freepascal

[Matias Vara]

Hi and thanks for the answers,

This feature seems to be a compiler intrinsic at least in the Intel C
> compiler. We don't have anything similar, so you have to fall back either
> to an asm procedure or a line of inline assembler. The compiler is also
> not doing an optimization similar to this. Free Pascal's inline assembler
> supports the PAUSE instruction though.
>
>
good to know that.


> But unless you plan to use this in a multithreaded spinloop because you're
> loading multiple cores of the CPU, it's better to let the operating system
> handle the wait. This instruction is certainly not the way to fix a "my
> app uses 100% CPU" scenario, just saying.
>
> Charlie


I am currently investigating the use of this instruction in my kernel. I
have wait-loops when accessing shared resources in a multicore system so
that could be a place to use it.
Also, I have situations in which the core just spends time in a loop so
this instruction may help to reduce energy consumption.  All this work is
however very experimental.


Matias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Lazarus Release 1.8

[Matias Vara]

Hello,

2017-12-07 9:36 GMT+01:00 Mattias Gaertner :

> The Lazarus team is glad to announce the release of Lazarus 1.8.
>
> The release was built with FPC 3.0.4.
> The previous release Lazarus 1.6.4 was built with FPC 3.0.2.
>
> Here is the list of changes for Lazarus and Free Pascal:
> http://wiki.lazarus.freepascal.org/Lazarus_1.8.0_release_notes
> http://wiki.lazarus.freepascal.org/User_Changes_3.0.4
>
> Here is the list of fixes for Lazarus 1.8.x:
> http://wiki.freepascal.org/Lazarus_1.8_fixes_branch
>
> The release is available for download on SourceForge:
> http://sourceforge.net/projects/lazarus/files/
>
> Choose your CPU, OS, distro and then the "Lazarus 1.8.0" directory.
>
> Checksums for the SourceForge files:
> http://www.lazarus-ide.org/index.php?page=checksums#1_8_0
>
> Minimum requirements:
>
> Windows:
> 2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit.
> optional qt 4.5 or 5.6 for qt apps
>
> FreeBSD/Linux:
> gtk 2.8 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit.
>
> Mac OS X:
> 10.5 to 10.12; Carbon (32bit), Cocoa (64bit, not stable), qt and qt5 (32
> or 64bit).
>
> The svn tag is
> http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0
>
> For people who are blocked by SF, the Lazarus releases from SourceForge
> are mirrored at:
> ftp://ftp.freepascal.org/pub/lazarus/releases/
> and later at (after some time for synchronization)
> http://mirrors.iwi.me/lazarus/
>
> Mattias
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>


Congratulation! Great work!
I am glad to announce that Toro compiles perfectly in Lazarus 1.8 and FPC
3.0.4

Matias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] cpu_relax() in freepascal

[Matias Vara]

Hello everyone,

I want to implement the cpu_relax() function in order to use it inside
loops. However before, I would like to know if the fpc compiler is doing an
optimization of this kind.

Kinds regards, Matias.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] issue when enabling -O2

[Matias Vara]

Hello everyone,

I am getting an exception when I enable the -O2 optimization. More
precisaily, the line that stars with write_portd is corrupting the data
section. This is the pascal code:

function PciReadDword(const bus, device, func, regnum: UInt32): UInt32;
var
  Send: DWORD;
begin
  Send := $8000 or (bus shl 16) or (device shl 11) or (func shl 8) or
(regnum shl 2);
  write_portd(@Send, PCI_CONF_PORT_INDEX);
  read_portd(@Send, PCI_CONF_PORT_DATA);
  Result := Send;
end;

*which generates (without -02):*

.section
.text.n_arch_$$_pcireaddword$longword$longword$longword$longword$$longword,"x"
.balign 16,0x90
.globl ARCH_$$_PCIREADDWORD$LONGWORD$LONGWORD$LONGWORD$LONGWORD$$LONGWORD
ARCH_$$_PCIREADDWORD$LONGWORD$LONGWORD$LONGWORD$LONGWORD$$LONGWORD:
.Lc207:
.seh_proc ARCH_$$_PCIREADDWORD$LONGWORD$LONGWORD$LONGWORD$LONGWORD$$LONGWORD
.Ll464:
# [992] begin
pushq %rbp
.seh_pushreg %rbp
.Lc209:
.Lc210:
movq %rsp,%rbp
.Lc211:
leaq -80(%rsp),%rsp
.seh_stackalloc 80
.seh_endprologue
# Var bus located at rbp-8, size=OS_32
# Var device located at rbp-16, size=OS_32
# Var func located at rbp-24, size=OS_32
# Var regnum located at rbp-32, size=OS_32
# Var $result located at rbp-40, size=OS_32
# Var Send located at rbp-48, size=OS_32
movl %ecx,-8(%rbp)
movl %edx,-16(%rbp)
movl %r8d,-24(%rbp)
movl %r9d,-32(%rbp)
.Ll465:
# [993] Send := $8000 or (bus shl 16) or (device shl 11) or (func shl
8) or (regnum shl 2);
movl -8(%rbp),%eax
shll $16,%eax
orl $2147483648,%eax
movl -16(%rbp),%edx
shll $11,%edx
orl %eax,%edx
movl -24(%rbp),%eax
shll $8,%eax
orl %edx,%eax
movl -32(%rbp),%edx
shll $2,%edx
orl %eax,%edx
movl %edx,-48(%rbp)
.Ll466:
# [995] write_portd(@Send, PCI_CONF_PORT_INDEX);
leaq -48(%rbp),%rcx
movl $3320,%edx
call ARCH_$$_WRITE_PORTD$POINTER$WORD
.Ll467:
# [996] read_portd(@Send, PCI_CONF_PORT_DATA);
leaq -48(%rbp),%rcx
movl $3324,%edx
call ARCH_$$_READ_PORTD$POINTER$WORD
.Ll468:
# [997] Result := Send;
movl -48(%rbp),%eax
movl %eax,-40(%rbp)
.Ll469:
# [998] end;
movl -40(%rbp),%eax
nop
leaq (%rbp),%rsp
popq %rbp
ret
.seh_endproc
.Lc208:
.Lt28:
.Ll470:

*and with -O2:*

.section .text.n_arch_$$_pciwriteword$word$word$word$word$word,"x"
.balign 16,0x90
.globl ARCH_$$_PCIWRITEWORD$WORD$WORD$WORD$WORD$WORD
ARCH_$$_PCIWRITEWORD$WORD$WORD$WORD$WORD$WORD:
.Lc148:
# Temps allocated between rbp-16 and rbp-8
.seh_proc ARCH_$$_PCIWRITEWORD$WORD$WORD$WORD$WORD$WORD
.Ll471:
# [1014] begin
pushq %rbp
.seh_pushreg %rbp
.Lc150:
.Lc151:
movq %rsp,%rbp
.Lc152:
leaq -48(%rsp),%rsp
.seh_stackalloc 48
# Var bus located in register ax
# Var device located in register dx
# Var func located in register r8w
# Var regnum located in register r9w
# Var value located in register cx
movq %rbx,-16(%rbp)
.seh_savereg %rbx, 32
.seh_endprologue
# Var Send located at rbp-8, size=OS_32
movw %cx,%ax
movw 48(%rbp),%bx
# PeepHole Optimization,var11
.Ll472:
# [1015] Send := $8000 or (bus shl 16) or (device shl 11) or (func shl
8) or (regnum and $fc);
andl $65535,%eax
shll $16,%eax
orl $2147483648,%eax
# PeepHole Optimization,var11
andl $65535,%edx
shll $11,%edx
orl %eax,%edx
# PeepHole Optimization,var11
andl $65535,%r8d
shll $8,%r8d
orl %edx,%r8d
# PeepHole Optimization,var1
# PeepHole Optimization,var11
andl $252,%r9d
orl %r8d,%r9d
movl %r9d,-8(%rbp)
.Ll473:
# [1016] write_portd(@Send, PCI_CONF_PORT_INDEX);
leaq -8(%rbp),%rcx
movl $3320,%edx
call ARCH_$$_WRITE_PORTD$POINTER$WORD
.Ll474:
# [1017] write_portw(value, PCI_CONF_PORT_DATA);
movw %bx,%cx
# Var value located in register cx
# PeepHole Optimization,var11
andl $65535,%ecx
movl $3324,%edx
call ARCH_$$_WRITE_PORTW$WORD$WORD
.Ll475:
# [1018] end;
movq -16(%rbp),%rbx
leaq (%rbp),%rsp
popq %rbp
ret
.seh_endproc

The first thing that I realize was the the optimized version is not
generating the correct source when is exiting since it should return
"Send", but am I right? The assembler code of write_portd remains the same,
Am I missing something?

Regards, Matias.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] issue when enabling -O2

[Matias Vara]

Thank you very much Karol, I completly missed this point during the
development of my kernel (Or maybe I had in mind sometime ago but I forgot
it)
It was only when I decided to play with -02 that all these issues arrised.

Matias

2018-01-10 17:34 GMT+01:00 Karoly Balogh (Charlie/SGR) <
char...@scenergy.dfmk.hu>:

> Hi,
>
> On Wed, 10 Jan 2018, Matias Vara wrote:
>
> > Hi Karol and thanks you very much! I got confused with the function
> > names, I feel very sorry.As I said in my previous email, I fixed by
> > rewriting the assembler function. However, I don't why it worked.
>
> By accident. Simply the register/stack/memory layout being different upon
> entry, and it worked by pure luck.
>
> > So I understand you correctly, if I use assembler in my procedures there
> > could be a risk that I trash a variable that the compiler is using.
>
> Yes. All operating systems and CPU architectures define a so called ABI or
> calling convention, which functions must respect. This details which
> registers are the parameters to be passed on, and which registers are free
> to destroy in a function and which ones *MUST* be saved/preserved (usually
> on the stack). There's no way around this. The compiler will expect that
> your assembly subfunctions play by the rules.
>
> See here, for example, for x86:
> https://en.wikipedia.org/wiki/X86_calling_conventions
>
> > Is  the compiler warning me about this?
>
> No. Assembly is quite a minefield in this regard. If you use assembler,
> the compiler assumes you know what you're doing, and doesn't analyze the
> assembler function. You have to respect the ABI of your CPU *AND* target
> platform by hand, and save the nonvolatile registers.
>
> (This is BTW, not Free Pascal specific. Delphi does the same, or more or
> less any other language which supports inline assembly.)
>
> Charlie
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] issue when enabling -O2

[Matias Vara]

Hello,

2018-01-10 18:03 GMT+01:00 Karoly Balogh (Charlie/SGR) <
char...@scenergy.dfmk.hu>:

> Hi,
>
> On Wed, 10 Jan 2018, Matias Vara wrote:
>
> > Thank you very much Karol, I completly missed this point during the
> > development of my kernel (Or maybe I had in mind sometime ago but I
> > forgot it)It was only when I decided to play with -02 that all these
> > issues arrised.
>
> BTW, your code (as shown by the parameter passing in your assembler dumps)
> seems to use the Microsoft x64 calling convention, which declares RSI
> value as callee-saved, and then your code overwrites that without saving.
>
> So the fact that your code overwrites it, could be the culprit. (And then
> the OUTSD instruction also increases RSI by 4, so even if that MOV
> wouldn't be there, you'd still need to save it.)
>
> Also note that the 64bit x86-64 ABI is very different between Linux and
> Windows, for example.
>
>
Thanks, I am going to review all the assembler code.


> BTW, developing a kernel in Pascal is cool... ;)
>

It is indeed :)

Matias


>
> Charlie
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] issue when enabling -O2

[Matias Vara]

2018-01-10 18:09 GMT+01:00 Karoly Balogh (Charlie/SGR) <
char...@scenergy.dfmk.hu>:

> Hi,
>
> On Wed, 10 Jan 2018, Matias Vara wrote:
>
> > BTW, this only applies to inline assembler functions rigth? In the case
> > of normal procedures that contains a block asm end; there is no problem,
> > Am I right?
>
> No, it applies to *ALL* assembler code. Also inline blocks. The only
> difference is, for blocks you can hint the compiler which registers you
> use, so the compiler can also tailor code which improves the interaction
> with your assembler code:
>
> https://www.freepascal.org/docs-html/ref/refse87.html
>
> This is not true for pure assembler functions tho', for performance
> reasons among others.
>
> Charlie
>

This is very interesting.

Thanks a lot.



> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] issue when enabling -O2

[Matias Vara]

I think the problem was the way write_portd() is implemented:

procedure write_portd(const Data: Pointer; const Port: Word); {$IFDEF
ASMINLINE} inline; {$ENDIF}
asm // RCX: data, RDX: port
  {$IFDEF LINUX} mov dx, port {$ENDIF}
mov rsi, data // DX=port
outsd
end;

If I replace with something that does not use the outsd instruction, it
works fine.

Matias

2018-01-10 15:55 GMT+01:00 Matias Vara <matiasev...@gmail.com>:

> Hello everyone,
>
> I am getting an exception when I enable the -O2 optimization. More
> precisaily, the line that stars with write_portd is corrupting the data
> section. This is the pascal code:
>
> function PciReadDword(const bus, device, func, regnum: UInt32): UInt32;
> var
>   Send: DWORD;
> begin
>   Send := $8000 or (bus shl 16) or (device shl 11) or (func shl 8) or
> (regnum shl 2);
>   write_portd(@Send, PCI_CONF_PORT_INDEX);
>   read_portd(@Send, PCI_CONF_PORT_DATA);
>   Result := Send;
> end;
>
> *which generates (without -02):*
>
> .section .text.n_arch_$$_pcireaddword$longword$longword$longword$
> longword$$longword,"x"
> .balign 16,0x90
> .globl ARCH_$$_PCIREADDWORD$LONGWORD$LONGWORD$LONGWORD$LONGWORD$$LONGWORD
> ARCH_$$_PCIREADDWORD$LONGWORD$LONGWORD$LONGWORD$LONGWORD$$LONGWORD:
> .Lc207:
> .seh_proc ARCH_$$_PCIREADDWORD$LONGWORD$LONGWORD$LONGWORD$LONGWORD$$
> LONGWORD
> .Ll464:
> # [992] begin
> pushq %rbp
> .seh_pushreg %rbp
> .Lc209:
> .Lc210:
> movq %rsp,%rbp
> .Lc211:
> leaq -80(%rsp),%rsp
> .seh_stackalloc 80
> .seh_endprologue
> # Var bus located at rbp-8, size=OS_32
> # Var device located at rbp-16, size=OS_32
> # Var func located at rbp-24, size=OS_32
> # Var regnum located at rbp-32, size=OS_32
> # Var $result located at rbp-40, size=OS_32
> # Var Send located at rbp-48, size=OS_32
> movl %ecx,-8(%rbp)
> movl %edx,-16(%rbp)
> movl %r8d,-24(%rbp)
> movl %r9d,-32(%rbp)
> .Ll465:
> # [993] Send := $8000 or (bus shl 16) or (device shl 11) or (func shl
> 8) or (regnum shl 2);
> movl -8(%rbp),%eax
> shll $16,%eax
> orl $2147483648,%eax
> movl -16(%rbp),%edx
> shll $11,%edx
> orl %eax,%edx
> movl -24(%rbp),%eax
> shll $8,%eax
> orl %edx,%eax
> movl -32(%rbp),%edx
> shll $2,%edx
> orl %eax,%edx
> movl %edx,-48(%rbp)
> .Ll466:
> # [995] write_portd(@Send, PCI_CONF_PORT_INDEX);
> leaq -48(%rbp),%rcx
> movl $3320,%edx
> call ARCH_$$_WRITE_PORTD$POINTER$WORD
> .Ll467:
> # [996] read_portd(@Send, PCI_CONF_PORT_DATA);
> leaq -48(%rbp),%rcx
> movl $3324,%edx
> call ARCH_$$_READ_PORTD$POINTER$WORD
> .Ll468:
> # [997] Result := Send;
> movl -48(%rbp),%eax
> movl %eax,-40(%rbp)
> .Ll469:
> # [998] end;
> movl -40(%rbp),%eax
> nop
> leaq (%rbp),%rsp
> popq %rbp
> ret
> .seh_endproc
> .Lc208:
> .Lt28:
> .Ll470:
>
> *and with -O2:*
>
> .section .text.n_arch_$$_pciwriteword$word$word$word$word$word,"x"
> .balign 16,0x90
> .globl ARCH_$$_PCIWRITEWORD$WORD$WORD$WORD$WORD$WORD
> ARCH_$$_PCIWRITEWORD$WORD$WORD$WORD$WORD$WORD:
> .Lc148:
> # Temps allocated between rbp-16 and rbp-8
> .seh_proc ARCH_$$_PCIWRITEWORD$WORD$WORD$WORD$WORD$WORD
> .Ll471:
> # [1014] begin
> pushq %rbp
> .seh_pushreg %rbp
> .Lc150:
> .Lc151:
> movq %rsp,%rbp
> .Lc152:
> leaq -48(%rsp),%rsp
> .seh_stackalloc 48
> # Var bus located in register ax
> # Var device located in register dx
> # Var func located in register r8w
> # Var regnum located in register r9w
> # Var value located in register cx
> movq %rbx,-16(%rbp)
> .seh_savereg %rbx, 32
> .seh_endprologue
> # Var Send located at rbp-8, size=OS_32
> movw %cx,%ax
> movw 48(%rbp),%bx
> # PeepHole Optimization,var11
> .Ll472:
> # [1015] Send := $8000 or (bus shl 16) or (device shl 11) or (func shl
> 8) or (regnum and $fc);
> andl $65535,%eax
> shll $16,%eax
> orl $2147483648,%eax
> # PeepHole Optimization,var11
> andl $65535,%edx
> shll $11,%edx
> orl %eax,%edx
> # PeepHole Optimization,var11
> andl $65535,%r8d
> shll $8,%r8d
> orl %edx,%r8d
> # PeepHole Optimization,var1
> # PeepHole Optimization,var11
> andl $252,%r9d
> orl %r8d,%r9d
> movl %r9d,-8(%rbp)
> .Ll473:
> # [1016] write_portd(@Send, PCI_CONF_PORT_INDEX);
> leaq -8(%rbp),%rcx
> movl $3320,%edx
> call ARCH_$$_WRITE_PORTD$POINTER$WORD
> .Ll474:
> # [1017] write_portw(value, PCI_CONF_PORT_DATA);
> movw %bx,%cx
> # Var value located in register cx
> # PeepHole Optimization,var11
> andl $65535,%ecx
> movl $3324,%edx
> call ARCH_$$_WRITE_PORTW$WORD$WORD
> .Ll475:
> # [1018] end;
> movq -16(%rbp),%rbx
> leaq (%rbp),%rsp
> popq %rbp
> ret
> .seh_endproc
>
> The first thing that I realize was the the optimized version is not
> generating the correct source when is exiting since it should return
> "Send", but am I right? The assembler code of write_portd remains the same,
> Am I missing something?
>
> Regards, Matias.
>
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] issue when enabling -O2

[Matias Vara]

Hi Karol and thanks you very much! I got confused with the function names,
I feel very sorry.
As I said in my previous email, I fixed by rewriting the assembler
function. However, I don't why it worked.
So I understand you correctly, if I use assembler in my procedures there
could be a risk that I trash a variable that the compiler is using. Is the
compiler warning me about this?

Matias

2018-01-10 17:14 GMT+01:00 Karoly Balogh (Charlie/SGR) <
char...@scenergy.dfmk.hu>:

> Hi,
>
> On Wed, 10 Jan 2018, Matias Vara wrote:
>
> > I am getting an exception when I enable the -O2 optimization. More
> > precisaily, the line that stars with write_portd is corrupting the
> > data section. This is the pascal code:
> >
> > function PciReadDword(const bus, device, func, regnum: UInt32): UInt32;
> > var
> >   Send: DWORD;
> > begin
> >   Send := $8000 or (bus shl 16) or (device shl 11) or (func shl 8)
> or (regnum shl 2);
> >   write_portd(@Send, PCI_CONF_PORT_INDEX);
> >   read_portd(@Send, PCI_CONF_PORT_DATA);
> >   Result := Send;
> > end;
> >
> > which generates (without -02):
> >
> > .section .text.n_arch_$$_pcireaddword$longword$longword$longword$
> longword$$longword,"x"
> > .balign 16,0x90
> > .globl ARCH_$$_PCIREADDWORD$LONGWORD$LONGWORD$LONGWORD$LONGWORD$$
> LONGWORD
> > ARCH_$$_PCIREADDWORD$LONGWORD$LONGWORD$LONGWORD$LONGWORD$$LONGWORD:
> >
> > (***shipp***)
> >
> > and with -O2:
> >
> > .section .text.n_arch_$$_pciwriteword$word$word$word$word$word,"x"
> > .balign 16,0x90
> > .globl ARCH_$$_PCIWRITEWORD$WORD$WORD$WORD$WORD$WORD
> > ARCH_$$_PCIWRITEWORD$WORD$WORD$WORD$WORD$WORD:
> >
> > The first thing that I realize was the the optimized version is not
> > generating the correct source when is exiting since it should return
> > "Send", but am I right? The assembler code of write_portd remains the
> > same, Am I missing something?
>
> The -O2 version of the function you sent is from a different one, it's
> from a Write function, not a Read... So no wonder it doesn't return
> anything... :)
>
> BTW, -O2 uses register variables, while -O- doesn't. If your assembler
> trashes one of them without preserving one, it can lead to crashes...
> But there could be many other reasons.
>
> Without seeing the actual assembler functions it's hard to tell.
>
> Charlie
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] issue when enabling -O2

[Matias Vara]

BTW, this only applies to inline assembler functions rigth? In the case of
normal procedures that contains a block asm end; there is no problem, Am I
right?

Matias

2018-01-10 17:51 GMT+01:00 Matias Vara <matiasev...@gmail.com>:

> Thank you very much Karol, I completly missed this point during the
> development of my kernel (Or maybe I had in mind sometime ago but I forgot
> it)
> It was only when I decided to play with -02 that all these issues arrised.
>
> Matias
>
> 2018-01-10 17:34 GMT+01:00 Karoly Balogh (Charlie/SGR) <
> char...@scenergy.dfmk.hu>:
>
>> Hi,
>>
>> On Wed, 10 Jan 2018, Matias Vara wrote:
>>
>> > Hi Karol and thanks you very much! I got confused with the function
>> > names, I feel very sorry.As I said in my previous email, I fixed by
>> > rewriting the assembler function. However, I don't why it worked.
>>
>> By accident. Simply the register/stack/memory layout being different upon
>> entry, and it worked by pure luck.
>>
>> > So I understand you correctly, if I use assembler in my procedures there
>> > could be a risk that I trash a variable that the compiler is using.
>>
>> Yes. All operating systems and CPU architectures define a so called ABI or
>> calling convention, which functions must respect. This details which
>> registers are the parameters to be passed on, and which registers are free
>> to destroy in a function and which ones *MUST* be saved/preserved (usually
>> on the stack). There's no way around this. The compiler will expect that
>> your assembly subfunctions play by the rules.
>>
>> See here, for example, for x86:
>> https://en.wikipedia.org/wiki/X86_calling_conventions
>>
>> > Is  the compiler warning me about this?
>>
>> No. Assembly is quite a minefield in this regard. If you use assembler,
>> the compiler assumes you know what you're doing, and doesn't analyze the
>> assembler function. You have to respect the ABI of your CPU *AND* target
>> platform by hand, and save the nonvolatile registers.
>>
>> (This is BTW, not Free Pascal specific. Delphi does the same, or more or
>> less any other language which supports inline assembly.)
>>
>> Charlie
>>
>> ___
>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>
>
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] issue when enabling -O2

[Matias Vara]

After fixing the assembler code and other issues, e.g., interruption
handlers were not restoring all registers, I observed an speed up of ~12%
with -O2 when running a simple webserver example. That's very impresive!

Thanks for you help, Matias.

2018-01-10 18:19 GMT+01:00 Matias Vara <matiasev...@gmail.com>:

>
> 2018-01-10 18:09 GMT+01:00 Karoly Balogh (Charlie/SGR) <
> char...@scenergy.dfmk.hu>:
>
>> Hi,
>>
>> On Wed, 10 Jan 2018, Matias Vara wrote:
>>
>> > BTW, this only applies to inline assembler functions rigth? In the case
>> > of normal procedures that contains a block asm end; there is no problem,
>> > Am I right?
>>
>> No, it applies to *ALL* assembler code. Also inline blocks. The only
>> difference is, for blocks you can hint the compiler which registers you
>> use, so the compiler can also tailor code which improves the interaction
>> with your assembler code:
>>
>> https://www.freepascal.org/docs-html/ref/refse87.html
>>
>> This is not true for pure assembler functions tho', for performance
>> reasons among others.
>>
>> Charlie
>>
>
> This is very interesting.
>
> Thanks a lot.
>
>
>
>> ___
>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>
>
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] question about _fpc_local_unwind

[Matias Vara]

Thanks for the answer, I will imitate in Toro the behavior of Win64.

Matias


2018-02-01 20:49 GMT+01:00 Jonas Maebe <jo...@freepascal.org>:

> On 01/02/18 16:24, Matias Vara wrote:
>
>> I partial answered my question by reading https://www.freepascal.org/doc
>> s-html/ref/refse114.html. So I think _fpc_local_unwind() is used to call
>> the finally section when "Exit" is executed in the "Try" section. It is not
>> clear yet what the parameters "frame,target: Pointer" are meant to. I
>> checked the code generated in Linux and is a bit different. It is base on
>> the functions FPC_PUSHEXCEPTADDR and FPC_POPADDRSTACK, which It seems much
>> more clear. Is it possible to generate a similar code in the case of Win64?
>> In other words, is it possible to tell the compiler "generate the
>> 'try-finally-end' block as in Linux"? I don't think so but It is worth to
>> ask.
>>
>
> No, it is not possible. On Win64 the compiler and RTL use so-called
> structured exception handling (SEH), which is required to interoperate with
> code generated by other compilers. See https://msdn.microsoft.com/en-
> us/library/windows/desktop/ms680657(v=vs.85).aspx for more information.
>
>
> Jonas
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] question about _fpc_local_unwind

[Matias Vara]

Hello,

2018-02-02 17:17 GMT+01:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> Am 02.02.2018 15 <02%2002%2020%2018%2015>:50 schrieb "Matias Vara" <
> matiasev...@gmail.com>:
>
> Thanks for the answer, I will imitate in Toro the behavior of Win64.
>
>
> Maybe it wound be better if you try to use the i386-embedded or
> x86_64-embedded targets. The non-embedded targets are simply not geared
> towards usage on a bare platform
>
>
Thanks for the suggestion, I don't think I am able to do that since the
whole kernel  compiles well by using the Win64 target. So I am not planing
to change the target. I notice that the code is in rtl/win64/seh64.inc so I
am starting to try to understand it.

Matias



> Regards,
> Sven
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] question about _fpc_local_unwind

[Matias Vara]

Hello,
I partial answered my question by reading
https://www.freepascal.org/docs-html/ref/refse114.html. So I think
_fpc_local_unwind() is used to call the finally section when "Exit" is
executed in the "Try" section. It is not clear yet what the parameters
"frame,target: Pointer" are meant to. I checked the code generated in Linux
and is a bit different. It is base on the functions FPC_PUSHEXCEPTADDR
and FPC_POPADDRSTACK, which It seems much more clear. Is it possible to
generate a similar code in the case of Win64? In other words, is it
possible to tell the compiler "generate the 'try-finally-end' block as in
Linux"? I don't think so but It is worth to ask.

Thanks, Matias.


2018-01-31 11:17 GMT+01:00 Matias Vara <matiasev...@gmail.com>:

> Hello eveyryone,
>
> in my rtl for torokernel, I have to implement "_fpc_local_unwind()"
> however I am not sure about the expected behavior of this function. It
> appers in the code when I use "Exit" inside a "try finally" structure. I
> would like to know what this function should do. So if someone can point me
> to some documetation would be very helpful,
>
> Thanks, Matias.
>
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] question about _fpc_local_unwind

[Matias Vara]

Hello eveyryone,

in my rtl for torokernel, I have to implement "_fpc_local_unwind()" however
I am not sure about the expected behavior of this function. It appers in
the code when I use "Exit" inside a "try finally" structure. I would like
to know what this function should do. So if someone can point me to some
documetation would be very helpful,

Thanks, Matias.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How __FPC_specific_handler() is invoked

[Matias Vara]

El mar., 24 jul. 2018 a las 13:57, Sven Barth via fpc-pascal (<
fpc-pascal@lists.freepascal.org>) escribió:

> Matias Vara  schrieb am Di., 24. Juli 2018, 11:04:
>
>> Hello,
>>
>> I am writing my own __FPC_specific_handler() but I can't figure out when
>> this function is registered. I guess this function is registered to the OS
>> to be invoked when an exception happens. In the assembler code I have
>> something like:
>>
>> .seh_handler __FPC_specific_handler,@unwind
>>
>> But I am puzzled by "@unwind". How is __FPC_specific_handler() invoked
>>
>
> To understand the .seh_*-pseudo instructions it's probably best to look at
> their initial check-in in the GNU assembler:
> https://sourceware.org/ml/binutils/2009-08/msg00193.html
>
> The handler function is invoked by Windows when an exception happens
> inside the code that is governed by the surrounding (implicit)
> .seh_(end)proc directives.
>
> Why are you writing your own handler?
>
>
Thanks for the answer, I am trying to make work the exceptions handling in
Toro kernel. Currently Toro is based on Win64 rtl. I think I will give up
with the Win64 RTL and move to a simpler RTL.

Matias



> Regards,
> Sven
>
>> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How __FPC_specific_handler() is invoked

[Matias Vara]

El mié., 25 jul. 2018 a las 14:33, Sven Barth via fpc-pascal (<
fpc-pascal@lists.freepascal.org>) escribió:

> Matias Vara  schrieb am Mi., 25. Juli 2018, 12:55:
>
>>
>> El mar., 24 jul. 2018 a las 13:57, Sven Barth via fpc-pascal (<
>> fpc-pascal@lists.freepascal.org>) escribió:
>>
>>> Matias Vara  schrieb am Di., 24. Juli 2018,
>>> 11:04:
>>>
>>>> Hello,
>>>>
>>>> I am writing my own __FPC_specific_handler() but I can't figure out
>>>> when this function is registered. I guess this function is registered to
>>>> the OS to be invoked when an exception happens. In the assembler code I
>>>> have something like:
>>>>
>>>> .seh_handler __FPC_specific_handler,@unwind
>>>>
>>>> But I am puzzled by "@unwind". How is __FPC_specific_handler() invoked
>>>>
>>>
>>> To understand the .seh_*-pseudo instructions it's probably best to look
>>> at their initial check-in in the GNU assembler:
>>> https://sourceware.org/ml/binutils/2009-08/msg00193.html
>>>
>>> The handler function is invoked by Windows when an exception happens
>>> inside the code that is governed by the surrounding (implicit)
>>> .seh_(end)proc directives.
>>>
>>> Why are you writing your own handler?
>>>
>>>
>> Thanks for the answer, I am trying to make work the exceptions handling
>> in Toro kernel. Currently Toro is based on Win64 rtl. I think I will give
>> up with the Win64 RTL and move to a simpler RTL.
>>
>
> I think I suggested some time ago already that you should use the embedded
> targets for writing a kernel. That's what they're there for after all.
>
>
You are right but I was a bit strong headed.

Thanks




> Regards,
> Sven
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] How __FPC_specific_handler() is invoked

[Matias Vara]

Hello,

I am writing my own __FPC_specific_handler() but I can't figure out when
this function is registered. I guess this function is registered to the OS
to be invoked when an exception happens. In the assembler code I have
something like:

.seh_handler __FPC_specific_handler,@unwind

But I am puzzled by "@unwind". How is __FPC_specific_handler() invoked?

Matias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Reduce gap between .text section and .data section in ELF

[Matias Vara]

Hi,

When I am compiling to ELF64, the linker is located the .text section at
the address 4MB and the .data at address 6MB. Is there any way to reduce
this 2MB gap between those sections?

Matias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Clone() in Linux x86-64 RTL

[Matias Vara via fpc-pascal]

Hello everyone,

I just checked that clone() is only present in i386 Linux RTL but it is not
defined in x86-64. Am I right? Or, I am missing something.

Matias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal