TGuid orm property (RTTI)

flydev · 2025-04-26 09:40:52

Hi there,

A small question, is TGuid supported as published property on Orm class? I have no issue with delphi but on FPC I get "Error: This kind of property cannot be published".

ab · 2025-04-26 09:47:00

It is a FPC limitation.
On recent Delphi (since Delphi XE6 IIRC), it works fine.

But you can still define it manually at model level using a virtual method.
https://synopse.info/forum/viewtopic.ph … 997#p10997

flydev · 2025-04-26 09:50:50

Hi @ab I had read this thread two times but missed this message! thanks

ab · 2025-04-26 10:48:56

In fact, TGuid fields are part of the regression tests:
https://github.com/search?q=repo%3Asyno … &type=code

flydev · 2025-07-22 14:23:52

Again, just a small question about TGUID as I’m hitting a cross-platform snag with FPC 3.2.2 but with TGUID defined as param on SOA:

IUserService = interface(IInvokable)
['...'] 
  function Read(const user_uuid: TGUID): TServiceCustomAnswer;
end;

- Win64 build (FPC 3.2.2): user_uuid arrives with the expected value.
- Linux x86-64 build (same sources & FPC version): user_uuid is always null.

Is this due to missing record RTTI for TGUID under FPC on Linux?
I can tackle the problem by passing it as RawUtf8, but I'am asking for my own knowledge.

thanks

Last edited by flydev (2025-07-22 14:24:58)

ab · 2025-07-23 14:44:21

1) Are you sure the FPC compiler is exactly the same?
I can't reproduce the error here.

2) Perhaps the TGuid type on Windows is not same as the one on non-Windows.
Try ctrl + click on the TGUID keyword in your method definition in Lazarus to see the definition of the TGuid type used.
Have you added the Windows unit in your unit "uses" clause?

flydev · 2025-07-23 17:03:53

1) Yes, but maybe I was unclear earlier, I cross-compile for both Windows and Linux on my Windows machine (FPC 3.2.2). I must say that I have compiled it directly on Ubuntu two months ago and got the very same issue.
2) no unit windows. I traced it to objpash.inc, line 134.

The server is behind nginx. The GUID param received on Linux is not null, but incorrect.

I compiled for linux and windows with "clean up and build" before posting here. Test results:

Linux: uuid is: 40918D38-0000-0000-0000-000000000000
Windows: uuid is: 3C28EA56-37FE-4ABC-A0B7-508D8C634E21 (as expected)

- Logs Linux:

$  +         AuthServer.TRestServerAuth(408199d0) URI GET api/main/UserService.ReadTest?user_uuid=3C28EA56-37FE-4ABC-A0B7-508D8C634E21 in=0 B
$ call               AuthServer.TRestServerAuth(408199d0) UserService.ReadTest len=40 ["3C28EA56-37FE-4ABC-A0B7-508D8C634E21"]
$ srvr               RestJwtAuth.TRestRoutingREST_JWT(70f85803e000)   Interface GET api/main/UserService.ReadTest?user_uuid=3C28EA56-37FE-4ABC-A0B7-508D8C634E21=200 out=51 B in 555us
$ ret                AuthServer.TRestServerAuth(408199d0) Interface len=51 uuid is: 40918D38-0000-0000-0000-000000000000

- Logs Windows:

+         AuthServer.TRestServerAuth(05ddad08) URI GET api/main/UserService.ReadTest?user_uuid=3C28EA56-37FE-4ABC-A0B7-508D8C634E21 in=0 B
call       AuthServer.TRestServerAuth(05ddad08) UserService.ReadTest len=40 ["3C28EA56-37FE-4ABC-A0B7-508D8C634E21"]
srvr      RestJwtAuth.TRestRoutingREST_JWT(06389a18)   Interface GET api/main/UserService.ReadTest?user_uuid=3C28EA56-37FE-4ABC-A0B7-508D8C634E21=200 out=51 B in 439us
ret       AuthServer.TRestServerAuth(05ddad08) Interface len=51 uuid is green: 3C28EA56-37FE-4ABC-A0B7-508D8C634E21

I will test with curl on the linux server without nginx in about 15 minutes.

Last edited by flydev (2025-07-23 17:05:37)

flydev · 2025-07-23 17:29:28

I just tested with `curl http://localhost:9088/api/main/UserService.ReadTest?user_uuid=3C28EA56-37FE-4ABC-A0B7-508D8C634E21` and I have the very same issue, result:

uuid is: 17868178-0000-0000-0000-000000000000

Then I have also compiled the server on ubuntu and same problem. FPC version on Ubuntu is 3.3.1. The lazarus project file is based on MVCServer.lpi with -Xm and compiled without optimization. I will test it with a simple and new project..

---

Edit:

I have created a new simple project on ubuntu and compiled, result is the same, the guid is wrong.

Last edited by flydev (2025-07-23 17:47:00)

ab · 2025-07-23 19:13:21

Try to debug a little bit more and

1) check perhaps TRestServerRoutingRest.DecodeUriParametersIntoJson: what is set to fCall^.InBody ?

2) check in TInterfaceMethodExecute.ExecuteJson what happens with the JSON.

flydev · 2025-07-23 22:23:00

I still didn't found where it happen exactly - in DecodeUriParametersIntoJson, InBody is built correctly with an uuid string in a json array. The issue seem happening elsewhere and deeper in ExecuteJson(). I will continue tomorrow.

I could observe that it happen only when the parameter is defined as const (required with TServiceCustomAnswer as return type) and then found that a method like:

function Example(const uuid: TGUID): RawUtf8;

.. produces the same problem. If using var/out TGUID, result is ok.

ab · 2025-07-24 08:09:16

So it may be because of the ABI, i.e. how parameters are passed on the stack.

On Windows such a record is passed on the stack as a pointer, i.e. as a single register.
But on FPC Linux it is passed by value, as two registers...

On FPC, we need to set "constref" to make it work.
Default "const" would pass it as two registers, not as a single register pointer.

The Win64 ABI register states:

Structs and unions of size 8, 16, 32, or 64 bits, and __m64 types, are passed as if they were integers of the same size. Structs or unions of other sizes are passed as a pointer to memory allocated by the caller.
https://learn.microsoft.com/en-us/cpp/b … er-passing

The SysV / POSIX ABI is not the same.

• Arguments of type _BitInt(N) with N <= 64 are in the INTEGER class.
• Arguments of type _BitInt(N) with N > 64 are classified as if they were implemented as struct of 64-bit integer fields
• If the size of an object is larger than eight eightbytes, or it contains unaligned fields, it has class MEMORY
• If there are no registers available for any eightbyte of an argument, the whole argument
is passed on the stack.
https://gitlab.com/x86-psABIs/x86-64-AB … ?job=build

So:
- the FPC code is correct, and default "const" should be passed as registers
- the current code in mORMOt seems not correct - I will fix it

flydev · 2025-07-24 09:13:34

at least I get some more doc to ingest.

ab wrote:

Default "const" would pass it as two registers, not as a single register pointer.

Aw nasty. Thanks you ab

mORMot Open Source

#1 2025-04-26 09:40:52

TGuid orm property (RTTI)

#2 2025-04-26 09:47:00

Re: TGuid orm property (RTTI)

#3 2025-04-26 09:50:50

Re: TGuid orm property (RTTI)

#4 2025-04-26 10:48:56

Re: TGuid orm property (RTTI)

#5 2025-07-22 14:23:52

Re: TGuid orm property (RTTI)

#6 2025-07-23 14:44:21

Re: TGuid orm property (RTTI)

#7 2025-07-23 17:03:53

Re: TGuid orm property (RTTI)

#8 2025-07-23 17:29:28

Re: TGuid orm property (RTTI)

#9 2025-07-23 19:13:21

Re: TGuid orm property (RTTI)

#10 2025-07-23 22:23:00

Re: TGuid orm property (RTTI)

#11 2025-07-24 08:09:16

Re: TGuid orm property (RTTI)

#12 2025-07-24 09:13:34

Re: TGuid orm property (RTTI)

Board footer