Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2009-09

RTTI method paramlist broken?

18 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Mattias Gaertner

It seems the order of parameters in the RTTI is different for 2.5.1 on x86_64.
On i386 it is still the same as 2.2.5.

I didn't find a flag telling me what order the RTTI is using.

Is this a bug, a feature, will i386 follow?

See TTypeData in unit typinfo: tkMethod

Mattias

Reply by email

Jonas Maebe
to Mattias Gaertner
Mattias Gaertner wrote 7 lines
It seems the order of parameters in the RTTI is different for 2.5.1 on x86_64. On i386 it is still the same as 2.2.5. I didn't find a flag telling me what order the RTTI is using. Is this a bug, a feature, will i386 follow?

I guess it's because of this:

r12891 | jonas | 2009-03-15 11:38:40 +0100 (Sun, 15 Mar 2009) | 5 lines Changed paths:
M /trunk/compiler/ncgrtti.pas
M /trunk/compiler/pdecsub.pas
M /trunk/compiler/symconst.pas

* removed any use of pushleftright_pocalls for non-i386 platforms, since
they always use the same parameter pushing order
* define the pushleftright_pocalls constant only for i386 so it cannot
be accidentally used anymore for other platforms

The parameter order was simply wrong in the rtti for x86_64, afaik. For i386, the parameter order depends on the used calling convention (and this was used correctly for the rtti), but other architectures it does not (while the rtti claimed otherwise).

Jonas

Reply by email

Mattias Gaertner
to Jonas Maebe
Show quoted text 30 lines
On 12 Sep 2009, at 11:20, Mattias Gaertner wrote: > It seems the order of parameters in the RTTI is different for 2.5.1 > on x86_64. > On i386 it is still the same as 2.2.5. > > I didn't find a flag telling me what order the RTTI is using. > > Is this a bug, a feature, will i386 follow? I guess it's because of this: r12891 | jonas | 2009-03-15 11:38:40 +0100 (Sun, 15 Mar 2009) | 5 lines Changed paths: M /trunk/compiler/ncgrtti.pas M /trunk/compiler/pdecsub.pas M /trunk/compiler/symconst.pas * removed any use of pushleftright_pocalls for non-i386 platforms, since they always use the same parameter pushing order * define the pushleftright_pocalls constant only for i386 so it cannot be accidentally used anymore for other platforms The parameter order was simply wrong in the rtti for x86_64, afaik. For i386, the parameter order depends on the used calling convention (and this was used correctly for the rtti), but other architectures it does not (while the rtti claimed otherwise).

Thanks.
I reverse the order now for non i386 and fpc 2.5+. Is this changed in the 2.4 too?

Mattias

Reply by email

Jonas Maebe
to Mattias Gaertner
Mattias Gaertner wrote 10 lines
On Sat, 12 Sep 2009 11:25:02 +0200 Jonas Maebe wrote: > The parameter order was simply wrong in the rtti for x86_64, afaik. > For i386, the parameter order depends on the used calling convention > (and this was used correctly for the rtti), but other architectures > it does not (while the rtti claimed otherwise). Thanks. I reverse the order now for non i386 and fpc 2.5+.

Previously, the order was reversed for non-i386 platforms depending on the calling convention. Now it should always be correct, both for i386 and for other architectures. Or do you mean that you now won't reverse the order anymore for non-i386?

Is this changed in the 2.4 too?

Yes. I'll also add it to the user changes wiki page.

Jonas

Reply by email

Mattias Gaertner
to Jonas Maebe
Show quoted text 18 lines
On 12 Sep 2009, at 11:49, Mattias Gaertner wrote: > On Sat, 12 Sep 2009 11:25:02 +0200 > Jonas Maebe wrote: > >> The parameter order was simply wrong in the rtti for x86_64, afaik. >> For i386, the parameter order depends on the used calling >> convention (and this was used correctly for the rtti), but other >> architectures it does not (while the rtti claimed otherwise). > > Thanks. > I reverse the order now for non i386 and fpc 2.5+. Previously, the order was reversed for non-i386 platforms depending on the calling convention. Now it should always be correct, both for i386 and for other architectures. Or do you mean that you now won't reverse the order anymore for non-i386?

Where is the calling convention in the RTTI stored?

> Is this changed in the 2.4 too? Yes. I'll also add it to the user changes wiki page.

Thanks again.

Mattias

Reply by email

Jonas Maebe
to Mattias Gaertner
Mattias Gaertner wrote 9 lines
On Sat, 12 Sep 2009 11:54:04 +0200 Jonas Maebe wrote: > Previously, the order was reversed for non-i386 platforms depending > on the calling convention. Now it should always be correct, both for > i386 and for other architectures. Or do you mean that you now won't > reverse the order anymore for non-i386? Where is the calling convention in the RTTI stored?

I don't think it is stored anywhere (does Delphi specify whether e.g. register or stdcall is used?). But you shouldn't need it for the parameter order, because depending on whether the calling convention specifies left-to-right or right-to-left pushing, the order of the parameters in the rtti also changes. That's why tests/webtbs/ tw12038.pp contains stdcall for all methods, because otherwise I can't use constant strings to check the results (since on i386, the default calling convention pushes from left to right instead of from right to left). This is at least Kylix-compatible.

Of course, the parameter order by itself is not enough to use this information to call anything, since it does specify how the parameters have to be passed (in registers, on the stack, whether the callee or caller is responsible to clean up the stack, ...).

Or do you use this information only for display or code completion purposes (so you always want the parameters in left-to-right order)? In that case, I don't think that's possible with rtti.

Jonas

Reply by email

Mattias Gaertner
to Jonas Maebe
Show quoted text 31 lines
On 12 Sep 2009, at 12:02, Mattias Gaertner wrote: > On Sat, 12 Sep 2009 11:54:04 +0200 > Jonas Maebe wrote: > >> Previously, the order was reversed for non-i386 platforms depending >> on the calling convention. Now it should always be correct, both >> for i386 and for other architectures. Or do you mean that you now >> won't reverse the order anymore for non-i386? > > Where is the calling convention in the RTTI stored? I don't think it is stored anywhere (does Delphi specify whether e.g. register or stdcall is used?). But you shouldn't need it for the parameter order, because depending on whether the calling convention specifies left-to-right or right-to-left pushing, the order of the parameters in the rtti also changes. That's why tests/webtbs/ tw12038.pp contains stdcall for all methods, because otherwise I can't use constant strings to check the results (since on i386, the default calling convention pushes from left to right instead of from right to left). This is at least Kylix-compatible. Of course, the parameter order by itself is not enough to use this information to call anything, since it does specify how the parameters have to be passed (in registers, on the stack, whether the callee or caller is responsible to clean up the stack, ...). Or do you use this information only for display or code completion purposes (so you always want the parameters in left-to-right order)? In that case, I don't think that's possible with rtti.

Yes, I need this to find compatible methods.
But RTTI lacks unitnames too. So this is just another reason to avoid using RTTI. Eventually I will replace that code in lazarus.

Mattias

Reply by email

Paul Ishenin
to Jonas Maebe: I don't think it is stored anywhere (does Delphi specify whether e.g. register or stdcall…
Jonas Maebe wrote 11 lines
> Where is the calling convention in the RTTI stored? I don't think it is stored anywhere (does Delphi specify whether e.g. register or stdcall is used?). But you shouldn't need it for the parameter order, because depending on whether the calling convention specifies left-to-right or right-to-left pushing, the order of the parameters in the rtti also changes. That's why tests/webtbs/tw12038.pp contains stdcall for all methods, because otherwise I can't use constant strings to check the results (since on i386, the default calling convention pushes from left to right instead of from right to left). This is at least Kylix-compatible.

Just tested with D2009:

  TStdcallMethod = procedure(Sender: TObject; Something: LongInt) of
object; stdcall;

If it is stdcall then methods must be listed in the rtti right-to-left but delphi stored Sender as first and Something as second.

Best regards,
Paul Ishenin.

Reply by email

Paul Ishenin
to Paul Ishenin
Paul Ishenin wrote 7 lines
Just tested with D2009: TStdcallMethod = procedure(Sender: TObject; Something: LongInt) of object; stdcall; If it is stdcall then methods must be listed in the rtti right-to-left but delphi stored Sender as first and Something as second.

To prove my founds I just wrote a small test application which compiles on D7, D2009, D2010 and FPC.

Please also note that all delphi versions stores calling convention in the rtti but info regards that only appeared in the D2010 comments.

Delphi output is:

procedure(address Sender: TObject; Something: Integer); register;
procedure(address Sender: TObject; Something: Integer); cdecl;
procedure(address Sender: TObject; Something: Integer); pascal;
procedure(address Sender: TObject; Something: Integer); stdcall;
procedure(address Sender: TObject; Something: Integer); safecall;

FPC output is:

procedure(address Sender: TObject; Something: LongInt);
procedure(Something: LongInt; address Sender: TObject);
procedure(address Sender: TObject; Something: LongInt);
procedure(Something: LongInt; address Sender: TObject);
procedure(Something: LongInt; address Sender: TObject);

Best regards,
Paul Ishenin.

Reply by email

Martin Schreiber
to Jonas Maebe: I don't think it is stored anywhere (does Delphi specify whether e.g. register or stdcall…
Jonas Maebe wrote 5 lines
Or do you use this information only for display or code completion purposes (so you always want the parameters in left-to-right order)? In that case, I don't think that's possible with rtti.

:-(
Bad news for MSEide. MSEide uses RTTI only and does not scan the RTL/FCL/component source. It is used to generate method skeletons by entering a method name in object inspector and to list compatible methods in the dropdownlist.

Martin

Reply by email

Jonas Maebe
to Paul Ishenin: To prove my founds I just wrote a small test application which compiles on D7, D2009,…
Paul Ishenin wrote 10 lines
Paul Ishenin wrote: > Just tested with D2009: > > TStdcallMethod = procedure(Sender: TObject; Something: LongInt) of > object; stdcall; > > If it is stdcall then methods must be listed in the rtti right-to- > left but delphi stored Sender as first and Something as second. To prove my founds I just wrote a small test application which compiles on D7, D2009, D2010 and FPC.

I've checked it with Kylix 3 and there it's indeed also always the same order. Apparently I made a mistake while testing. The FPC logic of storing the parameters in the rtti in the same order as the calling convention uses them dates from before my changes though. I'm not aware of any functionality in FPC or the RTL depending on this order, so it shouldn't be a problem to change it. Then again, I know almost nothing about any functionality using RTTI (other than reference counting), so I'll wait with changing anything to see whether someone else maybe knows a reason why this should not be changed.

Jonas

Reply by email

Mattias Gaertner
to Jonas Maebe
Show quoted text 24 lines
On 12 Sep 2009, at 15:10, Paul Ishenin wrote: > Paul Ishenin wrote: >> Just tested with D2009: >> >> TStdcallMethod = procedure(Sender: TObject; Something: LongInt) >> of object; stdcall; >> >> If it is stdcall then methods must be listed in the rtti right-to- >> left but delphi stored Sender as first and Something as second. > To prove my founds I just wrote a small test application which > compiles on D7, D2009, D2010 and FPC. I've checked it with Kylix 3 and there it's indeed also always the same order. Apparently I made a mistake while testing. The FPC logic of storing the parameters in the rtti in the same order as the calling convention uses them dates from before my changes though. I'm not aware of any functionality in FPC or the RTL depending on this order, so it shouldn't be a problem to change it. Then again, I know almost nothing about any functionality using RTTI (other than reference counting), so I'll wait with changing anything to see whether someone else maybe knows a reason why this should not be changed.

AFAIK only lazarus and MSEgui depend on the RTTI paramlist. Lazarus only uses them for speed reasons.

Mattias

Reply by email

Paul Ishenin
to Jonas Maebe: I've checked it with Kylix 3 and there it's indeed also always the same order. Apparently…
Jonas Maebe wrote 9 lines
I've checked it with Kylix 3 and there it's indeed also always the same order. Apparently I made a mistake while testing. The FPC logic of storing the parameters in the rtti in the same order as the calling convention uses them dates from before my changes though. I'm not aware of any functionality in FPC or the RTL depending on this order, so it shouldn't be a problem to change it. Then again, I know almost nothing about any functionality using RTTI (other than reference counting), so I'll wait with changing anything to see whether someone else maybe knows a reason why this should not be changed.

Extremely good news. Can you add at least calling convention field when you will change it? And the best would be take the full d2010 tkMethod declaration since it stores much more info there. Especially interesting are PPTypeInfo of result and param types and the calling convention field.

Best regards,
Paul Ishenin.

Reply by email

Paul Ishenin
to Paul Ishenin
Paul Ishenin wrote
And the best would be take the full d2010 tkMethod declaration since it stores much more info there.

Small correction:

Every delphi stores this info (except new attributes field) but only d2010 has the mostly full description of that info.

Best regards,
Paul Ishenin.

Reply by email

Michael Van Canneyt
to Jonas Maebe: I've checked it with Kylix 3 and there it's indeed also always the same order. Apparently…
Jonas Maebe wrote 22 lines
On 12 Sep 2009, at 15:10, Paul Ishenin wrote: > Paul Ishenin wrote: >> Just tested with D2009: >> >> TStdcallMethod = procedure(Sender: TObject; Something: LongInt) of object; >> stdcall; >> >> If it is stdcall then methods must be listed in the rtti right-to-left but >> delphi stored Sender as first and Something as second. > To prove my founds I just wrote a small test application which compiles on > D7, D2009, D2010 and FPC. I've checked it with Kylix 3 and there it's indeed also always the same order. Apparently I made a mistake while testing. The FPC logic of storing the parameters in the rtti in the same order as the calling convention uses them dates from before my changes though. I'm not aware of any functionality in FPC or the RTL depending on this order, so it shouldn't be a problem to change it. Then again, I know almost nothing about any functionality using RTTI (other than reference counting), so I'll wait with changing anything to see whether someone else maybe knows a reason why this should not be changed.

As far as I know, the RTTI should store the information in the order that the parameters appear in the declaration. It should not depend in any way on the actual calling convention. This is sufficient to create a declaration for an event handler.

But if it should be possible to decide on the basis of RTTI solely, whether a declared procedural property matches a published procedure on the ABI level, that would mean that the calling convention should also be available through RTTI, and so a field must be added to the RTTI, with a calling convention specifier.

So, in my opinion:
a) Put parameters in declared order.
b) Add (after result type name) a field with the calling convention.

That would help, BTW, to implement dispatch interfaces based on RTTI.

Michael.

Reply by email

Florian Klaempfl
to Martin Schreiber: :-( Bad news for MSEide. MSEide uses RTTI only and does not scan the RTL/FCL/component…
Show quoted text 11 lines
On Saturday 12 September 2009 12:14:07 Jonas Maebe wrote: > Or do you use this information only for display or code completion > purposes (so you always want the parameters in left-to-right order)? > In that case, I don't think that's possible with rtti. > :-( Bad news for MSEide. MSEide uses RTTI only and does not scan the RTL/FCL/component source. It is used to generate method skeletons by entering a method name in object inspector and to list compatible methods in the dropdownlist.

Fill a bug report so we can implement a D2010 compatible solution.

Reply by email