Re[2]: [fpc-devel]about the bug 2364
Hello Peter,
Wednesday, April 28, 2004, 4:02:59 PM, you wrote:
Hello all,
I have some ideas about the bug #2363 (Unfixed Error export problem).
Second way: storing exported items info in PPU.
PV That is possible. It needs a new ppuentry that will contain the following
PV items per export:
PV - procdef reference
PV - exported name
PV - exported index
May be it is possible to avoid adding new entries. I looked a
little... Two kinds of statements can be exported:
procedures/functions and (on some platforms) variables.
tvarsym contains a field varoptions that is a set of tvaroption.
Tvaroption already has vo_is_exported as a possible value.
tprocsym has a field is_global : boolean (unfortunately, only under
{$ifdef GDB}). This field could be easily changed to byte with 3
possible values: 0 - local, 1 - global, 2 - global and exported. That
could cause no changes in binary PPU structure and no changes in other
parts of compiler where this field is already used (only a typecast byte to
boolean is needed). Am I right?
--
Best regards,
Pavelmailto:[EMAIL PROTECTED]
___
fpc-devel maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Re[2]: [fpc-devel]about the bug 2364
Hello Peter,
Wednesday, April 28, 2004, 4:02:59 PM, you wrote:
Hello all,
I have some ideas about the bug #2363 (Unfixed Error export problem).
Second way: storing exported items info in PPU.
PV That is possible. It needs a new ppuentry that will contain the
following
PV items per export:
PV - procdef reference
PV - exported name
PV - exported index
May be it is possible to avoid adding new entries. I looked a
little... Two kinds of statements can be exported:
procedures/functions and (on some platforms) variables.
tvarsym contains a field varoptions that is a set of tvaroption.
Tvaroption already has vo_is_exported as a possible value.
tprocsym has a field is_global : boolean (unfortunately, only under
{$ifdef GDB}). This field could be easily changed to byte with 3
possible values: - local, 1 - global, 2 - global and exported. That
could cause no changes in binary PPU structure and no changes in other
parts of compiler where this field is already used (only a typecast byte
to
boolean is needed). Am I right?
That is not possible. Because the exports can be in a different unit. You
can't change fields in ppu entries that are in other units.
___
fpc-devel maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel]about the bug 2364
Hello all, I have some ideas about the bug #2363 (Unfixed Error export problem). I see two ways to solve this problem but I'm not sure that I'm able to realize them. First way (may be wrong): generating edata sections (or their analogs for non-Windows platforms) vor every unit that contains exports clause and making a chain of these sections using the same way as used to multi-units VMT generation. Second way: storing exported items info in PPU. -- Best regards, Pavelmailto:[EMAIL PROTECTED] ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]about the bug 2364
Hello all, I have some ideas about the bug #2363 (Unfixed Error export problem). I see two ways to solve this problem but I'm not sure that I'm able to realize them. First way (may be wrong): generating edata sections (or their analogs for non-Windows platforms) vor every unit that contains exports clause and making a chain of these sections using the same way as used to multi-units VMT generation. Don't know what you mean with multi-units VMT. A Class/Object/VMT is defined only in a single unit. I don't think that is possible. What to do with the index numbering across units? Second way: storing exported items info in PPU. That is possible. It needs a new ppuentry that will contain the following items per export: - procdef reference - exported name - exported index ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
