Sign in Join

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

Mailing lists / fpc-devel / 2004-08

PowerPC, TypInfo

9 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

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

Mattias Gaertner

I found a bug in the RTTI under powerpc.

Boolean properties stored in fields
(e.g. properrty MyBoolean: boolean read FMyBoolean) always returns false.

The GetOrdProp is used to read boolean values. It reads a longint and applies "and $ff" to get only the lowest byte. Under PowerPC the boolean value is stored just like under i386 in the first byte. Reading the longint under i386 works, but of course it does not under powerpc.

So, either the compiler is wrong or the GetOrdValue function is wrong.

Which one should I report?

It's one of the last show stoppers for Lazarus under Mac OS X.

Mattias

Reply by email

Mattias Gaertner
to Mattias Gaertner
Show quoted text 15 lines
I found a bug in the RTTI under powerpc. Boolean properties stored in fields (e.g. properrty MyBoolean: boolean read FMyBoolean) always returns false. The GetOrdProp is used to read boolean values. It reads a longint and applies "and $ff" to get only the lowest byte. Under PowerPC the boolean value is stored just like under i386 in the first byte. Reading the longint under i386 works, but of course it does not under powerpc. So, either the compiler is wrong or the GetOrdValue function is wrong. Which one should I report?

I just found out, that this is also the case for ShortInt, SmallInt, Word and Byte, but not for enums.

It's one of the last show stoppers for Lazarus under Mac OS X.

Mattias

Reply by email

Jonas Maebe
to Mattias Gaertner
Mattias Gaertner wrote 13 lines
> The GetOrdProp is used to read boolean values. It reads a longint and > applies "and $ff" to get only the lowest byte. Under PowerPC the > boolean > value is stored just like under i386 in the first byte. Reading the > longint under i386 works, but of course it does not under powerpc. > > So, either the compiler is wrong or the GetOrdValue function is wrong. > > Which one should I report? I just found out, that this is also the case for ShortInt, SmallInt, Word and Byte, but not for enums.

To me, the fact that it always reads a longint regardless of the size of the property seems to be inherently wrong. What if the last field of a class is a byte? Then you can read past the end of the class, possibly into unallocated memory causing a crash, no?

Jonas

Reply by email

Florian Klaempfl
to Jonas Maebe
Jonas Maebe wrote 21 lines
On 14 aug 2004, at 21:07, Mattias Gaertner wrote: >> The GetOrdProp is used to read boolean values. It reads a longint and >> applies "and $ff" to get only the lowest byte. Under PowerPC the boolean >> value is stored just like under i386 in the first byte. Reading the >> longint under i386 works, but of course it does not under powerpc. >> >> So, either the compiler is wrong or the GetOrdValue function is wrong. >> >> Which one should I report? > > > I just found out, that this is also the case for ShortInt, SmallInt, Word > and Byte, but not for enums. To me, the fact that it always reads a longint regardless of the size of the property seems to be inherently wrong. What if the last field of a class is a byte? Then you can read past the end of the class, possibly into unallocated memory causing a crash, no?

No. Classes are always allocated on the heap so the memory block is always at least a multiple of 4.

Reply by email

Mattias Gaertner
to Jonas Maebe: To me, the fact that it always reads a longint regardless of the size of the property…
Show quoted text 21 lines
On 14 aug 2004, at 21:07, Mattias Gaertner wrote: >> The GetOrdProp is used to read boolean values. It reads a longint and >> applies "and $ff" to get only the lowest byte. Under PowerPC the >> boolean >> value is stored just like under i386 in the first byte. Reading the >> longint under i386 works, but of course it does not under powerpc. >> >> So, either the compiler is wrong or the GetOrdValue function is wrong. >> >> Which one should I report? > > I just found out, that this is also the case for ShortInt, SmallInt, > Word > and Byte, but not for enums. To me, the fact that it always reads a longint regardless of the size of the property seems to be inherently wrong. What if the last field of a class is a byte? Then you can read past the end of the class, possibly into unallocated memory causing a crash, no?

Good point.
Looking at SetOrdProp, I see, that it works correct with PByte, PWord, PLongInt.
So GetOrdProp is buggy.

I will send a patch, when I completed the other tests.

Mattias

Reply by email

Jonas Maebe
to Florian Klaempfl: No. Classes are always allocated on the heap so the memory block is always at least a…
Florian Klaempfl wrote 7 lines
> To me, the fact that it always reads a longint regardless of the size > of the property seems to be inherently wrong. What if the last field > of a class is a byte? Then you can read past the end of the class, > possibly into unallocated memory causing a crash, no? No. Classes are always allocated on the heap so the memory block is always at least a multiple of 4.

So? What if the last field is a byte and is stored in the last byte of the e.g. 100 bytes that the class occupies? Keep in mind that getordprop does not necessarily read from a 4-byte aligned address. It simply reads 4 bytes from the start address of the field, and then ands the result with $ff if the size of the field was 1 byte.

Jonas

Reply by email

Mattias Gaertner
to Florian Klaempfl: No. Classes are always allocated on the heap so the memory block is always at least a…
Show quoted text 27 lines
Jonas Maebe wrote: > > On 14 aug 2004, at 21:07, Mattias Gaertner wrote: > >>> The GetOrdProp is used to read boolean values. It reads a longint and >>> applies "and $ff" to get only the lowest byte. Under PowerPC the >boolean>> value is stored just like under i386 in the first byte. Reading >the>> longint under i386 works, but of course it does not under powerpc. >>> >>> So, either the compiler is wrong or the GetOrdValue function is wrong. >>> >>> Which one should I report? >> >> >> I just found out, that this is also the case for ShortInt, SmallInt, >Word> and Byte, but not for enums. > > > To me, the fact that it always reads a longint regardless of the size of > > the property seems to be inherently wrong. What if the last field of a > class is a byte? Then you can read past the end of the class, possibly > into unallocated memory causing a crash, no? No. Classes are always allocated on the heap so the memory block is always at least a multiple of 4.

The longint is read from the start of the SmallInt, so if the class is packed, its adress is not a multiple of 4. Or are all class variables 4 byte aligned?

Mattias

Reply by email

Florian Klaempfl
to Jonas Maebe: So? What if the last field is a byte and is stored in the last byte of the e.g. 100 bytes…
Jonas Maebe wrote 18 lines
On 15 aug 2004, at 00:20, Florian Klaempfl wrote: >> To me, the fact that it always reads a longint regardless of the size >> of the property seems to be inherently wrong. What if the last field >> of a class is a byte? Then you can read past the end of the class, >> possibly into unallocated memory causing a crash, no? > > > No. Classes are always allocated on the heap so the memory block is > always at least a multiple of 4. So? What if the last field is a byte and is stored in the last byte of the e.g. 100 bytes that the class occupies? Keep in mind that getordprop does not necessarily read from a 4-byte aligned address. It simply reads 4 bytes from the start address of the field, and then ands the result with $ff if the size of the field was 1 byte.

Ops :) It seems I worked too much with my sparc ;)

Reply by email

Mattias Gaertner
to Mattias Gaertner: Good point. Looking at SetOrdProp, I see, that it works correct with PByte, PWord,…
Show quoted text 27 lines
On Sat, 14 Aug 2004 23:59:55 +0200 Jonas Maebe wrote: > > On 14 aug 2004, at 21:07, Mattias Gaertner wrote: > > >> The GetOrdProp is used to read boolean values. It reads a longint and > >> applies "and $ff" to get only the lowest byte. Under PowerPC the > >> boolean > >> value is stored just like under i386 in the first byte. Reading the > >> longint under i386 works, but of course it does not under powerpc. > >[...] > > I just found out, that this is also the case for ShortInt, SmallInt, > > Word > > and Byte, but not for enums. > > To me, the fact that it always reads a longint regardless of the size > of the property seems to be inherently wrong. What if the last field of > a class is a byte? Then you can read past the end of the class, > possibly into unallocated memory causing a crash, no? Good point. Looking at SetOrdProp, I see, that it works correct with PByte, PWord, PLongInt. So GetOrdProp is buggy. I will send a patch, when I completed the other tests.

Attached patch was tested under i386 and ppc.

Mattias

Reply by email