Re[6]: [fpc-devel] is smartlink of Win32 DLLs broken again? And a old FreeBSD port problem additionaly
Hello FPC Team, Please explain me why my yesterday's work remained be ignored? Practically, I think, I solved a problem at fixed a bug. Are you discordant with my way of solution or are waiting for diff? -- Best regards, Pavelmailto:[EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] generics
> Hi, > > I'm trying to add support for generics (templates) to fpc. > > Do we want to have a "generics" section (like "interface", > "implementation") or do we want a special source code type (like "unit", > "program") in the source code ? > > I'm tending to a special source code type "generic unit". > > The generic source code file (.pas,.pp) is installed (not the .ppu,.o). > Then in the 'uses' handler, when not finding a ppu, it reverts to the > pas file, and then finds that it is a special source code "generic unit" > or so, so it *doesnt* compile it right now, but 'uses' actually just > registers the generic classes as 'available for compilation later'. You only need 1 generic type at once. Why should a complete generic unit be used? Also using it as a unit is inconsistent with the way that units are handled and will require a lot of if..then parts in the unit loading code. And that code is already one of the most complex parts of the compiler. It is already on a after 2.0 todo list to be rewritten because of this complexity. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] generics
further infos: http://qc.borland.com/wc/qcmain.aspx?d=11168 Danny Milosavljevic wrote: Hi, I'm trying to add support for generics (templates) to fpc. Do we want to have a "generics" section (like "interface", "implementation") or do we want a special source code type (like "unit", "program") in the source code ? I'm tending to a special source code type "generic unit". The generic source code file (.pas,.pp) is installed (not the .ppu,.o). Then in the 'uses' handler, when not finding a ppu, it reverts to the pas file, and then finds that it is a special source code "generic unit" or so, so it *doesnt* compile it right now, but 'uses' actually just registers the generic classes as 'available for compilation later'. When first using a specialization declaration like 'GList', _then_ it is compiled (after injecting the specialization types to use) (where to? a special .o file like glist-system-integer.o or glist-someunit-someclass.o ? use a .ppu too ? I guess so) I'm leaving "advanced" features out for now, like "any" types (variant-interface to a generic), although it could be argued that the generic class could compile using the "any" types (most likely "Variant") later. Opinions? cheers, Danny ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] generics
Hi, I'm trying to add support for generics (templates) to fpc. Do we want to have a "generics" section (like "interface", "implementation") or do we want a special source code type (like "unit", "program") in the source code ? I'm tending to a special source code type "generic unit". The generic source code file (.pas,.pp) is installed (not the .ppu,.o). Then in the 'uses' handler, when not finding a ppu, it reverts to the pas file, and then finds that it is a special source code "generic unit" or so, so it *doesnt* compile it right now, but 'uses' actually just registers the generic classes as 'available for compilation later'. When first using a specialization declaration like 'GList', _then_ it is compiled (after injecting the specialization types to use) (where to? a special .o file like glist-system-integer.o or glist-someunit-someclass.o ? use a .ppu too ? I guess so) I'm leaving "advanced" features out for now, like "any" types (variant-interface to a generic), although it could be argued that the generic class could compile using the "any" types (most likely "Variant") later. Opinions? cheers, Danny -- www.keyserver.net key id A334AEA6 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[5]: [fpc-devel] is smartlink of Win32 DLLs broken again? And a old FreeBSD port problem additionaly
Hello all, It seems, I solved the smartlink problem. Solution: 1) in pexports.pas, I added into interface part of unit var BinaryContainsExports: boolean = false; 2) in pexports.pas, in first line of main body of read_exports procedure, I added begin BinaryContainsExports:=true; //NEW!!! DefString:=''; 3) in pmodules.pas, I added a reference to pexports into the uses clause of implementation part. 4) in pmodules.pas, I changed a line in proc_program procedure: INSTEAD if assigned(exportlib) and (target_info.system in [system_i386_win32,system_i386_wdosx]) and assigned(current_module._exports.first) then codesegment.concat(tai_const.create_sym(exportlib.edatalabel)); I MADE if assigned(exportlib) and (target_info.system in [system_i386_win32,system_i386_wdosx]) and BinaryContainsExports then codesegment.concat(tai_const.create_sym(exportlib.edatalabel)); That's all. The patched compiler builds my tests correctly. -- Best regards, Pavelmailto:[EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[4]: [fpc-devel] is smartlink of Win32 DLLs broken again? And a old FreeBSD port problem additionaly
Hello all, I found something that explains a loss of reference from PASCALMAIN module to edata module. In pmodules.pas, in proc_program procedure an inserting of this reference is provided. if assigned(exportlib) and (target_info.system in [system_i386_win32,system_i386_wdosx]) and assigned(current_module._exports.first) then But actually current_module._exports.first is nil (at least at this stage). The condition is false, inserting doesn't occur. Pavel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[3]: [fpc-devel] is smartlink of Win32 DLLs broken again? And a old FreeBSD port problem additionaly
Hello Peter, PVO> I'm not sure that you are right. There were a solution found that I can explain that reported smartlink problem is not a binutils problem. I fixed generated asm code and got correct dll. EDATA module: ** .section .bss .section .edata .globl _$PROGRAM$_L1 _$PROGRAM$_L1: .long 0 .long 0 .short 0 .short 0 .rva.L26 .long 1 .long 2 .long 2 .rva.L27 .rva.L28 .rva.L29 .L26: .ascii "CRPLUGIN.dll\000" .balign 4,0 .L27: .rva P$CRPLUGIN_MODULEPROC$LONGINT$TMAP$PCHAR$LONGINT$LONGINT$LONGWORD$LONGWORD$$LONGBOOL .rvaP$CRPLUGIN_MODULEDATAMODE$$LONGINT .balign 4,0 .L28: .rva.L30 .rva.L31 .balign 4,0 .L29: .short 1 .short 0 .balign 4,0 .balign 2,0 .L30: .ascii "ModuleDataMode\000" .balign 2,0 .L31: .ascii "ModuleProc\000" Non-patched PASCALMAIN module: ** .section .text .balign 4 .balign 4 .globl PASCALMAIN PASCALMAIN: .globl _P$CRPLUGIN_main _P$CRPLUGIN_main: pushl %ebp movl%esp,%ebp callFPC_INITIALIZEUNITS leave ret .balign 4 Fixed PASCALMAIN module: .section .text .balign 4 .balign 4 .globl PASCALMAIN PASCALMAIN: .globl _P$CRPLUGIN_main _P$CRPLUGIN_main: pushl %ebp movl%esp,%ebp callFPC_INITIALIZEUNITS leave ret .long _$PROGRAM$_L1 .balign 4 -- Best regards, Pavelmailto:[EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] is smartlink of Win32 DLLs broken again? And a old FreeBSD port problem additionaly
Hello Peter, PV> Since the problem is not in FPC code we can't fix it. I'm not sure that you are right. There were a solution found that was based on a code generated by compiler. An asm/obj module with PASCALMAIN conained a reference to a label which was located in an asm/obj module contained export data section. In current compiler, this label creating is supported but a creation of the reference from PASCALMAIN module is lost. Additionaly, I use ld version 2.15.91 20040904. -- Best regards, Pavelmailto:[EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for classes.inc: free items of InitHandlerList
Vincent Snijders wrote:
Hi,
Attached patch frees the items of the InitHandlerList. The items are
allocated in RegisterInitComponentHandler, but never seem to be freeed.
Heaptrc showed a memleak, when you ran lazarus with the cgi package
installed.
Further testing showed that the patch contained a bug. InitHandlerList
might not be created at all. Attached patch corrects also this case.
Sorry for the confusion.
Regards,
Vincent.
Index: rtl/objpas/classes/classes.inc
===
RCS file: /FPC/CVS/fpc/rtl/objpas/classes/classes.inc,v
retrieving revision 1.26
diff -u -r1.26 classes.inc
--- rtl/objpas/classes/classes.inc 13 Apr 2005 16:16:43 - 1.26
+++ rtl/objpas/classes/classes.inc 27 Apr 2005 08:02:25 -
@@ -1496,6 +1496,9 @@
ComponentPages.Free;
{!!!: GlobalNameSpace.Free;
GlobalNameSpace := nil;}
+ if (InitHandlerList<>Nil) then
+for i := 0 to InitHandlerList.Count - 1 do
+ TInitHandler(InitHandlerList.Items[I]).Free;
InitHandlerList.Free;
InitHandlerList:=Nil;
FindGlobalComponentList.Free;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] is smartlink of Win32 DLLs broken again? And a old FreeBSD port problem additionaly
> Hello all,
>
> 1) I tried now to build a dll with {$smartlink on} using 1.9.9 compiler
> built at beginning of April. The created DLL did not contain export
> names. An analysis of generated asm code pointed that although a
> global label at beginning of .rva-containing asm-file has been
> correctly created but the PASCALMAIN module did not contain a
> reference to this label. At result, all EDATAs sould be eliminated at
> linking stage.
Maybe a problem with binutils. The stripping of .stabs sections ("ld -s"
or using strip) is also broken with recent binutils. We can't use old
binutils since they can't link with recent cygwin libraries.
Since the problem is not in FPC code we can't fix it.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] is smartlink of Win32 DLLs broken again? And a old FreeBSD port problem additionaly
Hello all,
1) I tried now to build a dll with {$smartlink on} using 1.9.9 compiler
built at beginning of April. The created DLL did not contain export
names. An analysis of generated asm code pointed that although a
global label at beginning of .rva-containing asm-file has been
correctly created but the PASCALMAIN module did not contain a
reference to this label. At result, all EDATAs sould be eliminated at
linking stage.
2) Because I braced up, to write this letter :), I would also report a
old problem which I got using an old 1.1 FreeBSD port. I needed to
build a shared UDF library for MySQL. While loading created .so file,
I got an error message - something like "main entry point not found".
An analysis of asm code demonstated that global main function mas
named not "main" but had a name combined from a shared module name and
"_main", therefore the dynamic linker could not find main entry point.
At that time I solved this problem editing the asm code but this way
seems to be not normal.
Sincerely, Pavel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] patch for classes.inc: free items of InitHandlerList
Hi,
Attached patch frees the items of the InitHandlerList. The items are
allocated in RegisterInitComponentHandler, but never seem to be freeed.
Heaptrc showed a memleak, when you ran lazarus with the cgi package
installed.
Regards,
Vincent
Index: rtl/objpas/classes/classes.inc
===
RCS file: /FPC/CVS/fpc/rtl/objpas/classes/classes.inc,v
retrieving revision 1.26
diff -u -r1.26 classes.inc
--- rtl/objpas/classes/classes.inc 13 Apr 2005 16:16:43 - 1.26
+++ rtl/objpas/classes/classes.inc 27 Apr 2005 06:44:21 -
@@ -1496,6 +1496,8 @@
ComponentPages.Free;
{!!!: GlobalNameSpace.Free;
GlobalNameSpace := nil;}
+ for i := 0 to InitHandlerList.Count - 1 do
+TInitHandler(InitHandlerList.Items[I]).Free;
InitHandlerList.Free;
InitHandlerList:=Nil;
FindGlobalComponentList.Free;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
