The mORMot[1] sources could give you some info.
During runtime, it patches the exe-memory to redirect function calls.
Hard part was to get around the W^X memory protection on some BSD's.
Look at:
procedure PatchCode(Old,New: pointer; Size: integer; Backup: pointer;
inside SynCommons.pas
functio
On 14/04/2021 17:49, Alfred via fpc-devel wrote:
> The mORMot[1] sources could give you some info.
> During runtime, it patches the exe-memory to redirect function calls.
> Hard part was to get around the W^X memory protection on some BSD's.
>
> Look at:
>
> procedure PatchCode(Old,New: pointer;
On Wed, 14 Apr 2021, Jonas Maebe via fpc-devel wrote:
On 14/04/2021 17:49, Alfred via fpc-devel wrote:
The mORMot[1] sources could give you some info.
During runtime, it patches the exe-memory to redirect function calls.
Hard part was to get around the W^X memory protection on some BSD's.
Lo
Am 11.04.2021 um 23:38 schrieb Ryan Joseph via fpc-devel:
On Apr 11, 2021, at 3:33 PM, Sven Barth wrote:
Looking at it, it could be that there is a bug in
tarrayconstructornode.pass_typecheck that hasn't really surfaced yet... I'll
have to look at that first, but I don't know when I'll have
> On Apr 14, 2021, at 2:33 PM, Sven Barth wrote:
>
> Had a bit of time to look at this. You can try the attached patch. You can
> then check for both ado_IsConstructor and ado_IsArrayOfConst to detect such a
> mixed array.
It works but it thinks this array is array of const also so it's too
Am 14.04.2021 um 23:49 schrieb Ryan Joseph via fpc-devel:
On Apr 14, 2021, at 2:33 PM, Sven Barth wrote:
Had a bit of time to look at this. You can try the attached patch. You can then
check for both ado_IsConstructor and ado_IsArrayOfConst to detect such a mixed
array.
It works but it thi