Re: [fpc-pascal] Debug information
Am Tuesday 29 May 2012 01:42:12 schrieb Martin: On 28/05/2012 23:53, Rainer Stratmann wrote: Am Monday 28 May 2012 22:25:47 schrieb Martin: Check that you have not accidentally set any options that will block -gl, such as -Xs or maybe (may work but I do not know for sure) -Xg After changing options, change Build or Build all from run menu. All done, same effect (only addresses shown). I thought of other options that block the lineoutput, but can not imagine which one. Gets back to one of the questions of the last mail: Did you have a look at the exe size? The exe size is the easiest indicator, if debug info was added. The program size (in Linux) is nearly 3 times more than without debug info. Running out of ideas myself. May be someone else can help... Can you run with F9 in Lazarus? making sure the debugger is set up ( http://wiki.lazarus.freepascal.org/Debugger_Setup ) I will try later. The debugger should stop on a run error, and you should be able to get the stacktrace. It does not solve the initial problem, but one step at a time. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross compiling x86_64 on i386 Linux.
Bruce, If you are using a Debian derived distribution such as Ubuntu, you might find it easier to use debootstrap to create a 64 bit environment on your system and compile the program in that environment (see https://help.ubuntu.com/community/DebootstrapChroot for a guide). Then you can be sure that you have all the correct libraries in their standard paths, etc. In my set up, I compile for both 64 bit and 32 bit targets on a 64 bit machine and have separate debootstrap (chroots) for each target environment rather than compile in the development environment. This ensures that the final compilation takes place in a known clean environment. I also have a chroot for a win32 cross compiler. Once you have created the chroot for each target, all you need to do is to install the fpc debs in the appropriate environment (64 bit fpc for the 64 bit environment, 32 bit for the 32 bit environment), install any other libraries you need for the distribution repository and then compile the software in each chroot separately. The result will be executables built for each target and built in a clean environment. If you also want to generate distribution packages (debs), this is also the best way to go about it. Regards Tony Whyman MWA Software On 29/05/12 03:19, Bruce Tulloch wrote: Closer, but not quite there yet... To get this going I've (sshfs) mounted a 64 bit system on /mnt/engels and then attempted to cross-compile on the 32 bit system with: fpc -MDelphi -Scgi -CX -O3 -OoUNCERTAIN -OoREGVAR \ -Tlinux -Px86_64 -Xs -XX -va -l \ -dLCL -dLCLgtk2 -XR/mnt/engels This compiles but fails at the linker: Searching file /mnt/engels/usr/lib64/crtn.o... found Searching file /usr/local/opt/binutils/bin/x86_64-linux-ld... found Using util /usr/local/opt/binutils/bin/x86_64-linux-ld /usr/local/opt/binutils/bin/x86_64-linux-ld: skipping incompatible /lib/libpthread.so.0 when searching for /lib/libpthread.so.0 /usr/local/opt/binutils/bin/x86_64-linux-ld: cannot find /lib/libpthread.so.0 Error: Error while linking Fatal: There were 1 errors compiling module, stopping The linker /usr/local/opt/binutils/bin/x86_64-linux-ld was created using (an appropriately modified) fpcfixes_2.6/cross/buildcrossbinutils i.e. built to run on i386 and target x86_64 MYINTEL=i386 TARGETS_X86_64=linux and the pthread library is (presumably, given the -XR option) /mnt/engels/lib/libpthread.so which file reports as libpthread-2.11.3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped How can I find out why x86_64-linux-ld reports it as incompatible? Many thanks, Bruce. On 05/28/12 23:02, Jonas Maebe wrote: On 28 May 2012, at 14:56, Bruce Tulloch wrote: Am I correct to assume that if I drag in the x86_64 libraries I need from another x86_64 system, put them in a local directory and then reference then using the -XR option I can make this setup work? -XR is for pointing the compiler/linker to the top of a complete sysroot (i.e., a hierarchy with /lib, /usr/lib etc), not to a directory with just few handpicked libraries. For the latter, use the -Fl command line switch instead, possibly combined with -Xd (to prevent the compiler from passing the default system directories as search paths to the linker). And yes, that should indeed work fine. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Streaming of Generics
Ideally, I'd only like to write the streaming mechanism for each set of types (normal, anisstring, dynamic array, objects, interfaced objects) once, and use it for every set of items. However, there's no reasonable way to detect the type and do an execution for it. Ideally You can use the magic function TypeInfo() to detect the type of a generic parameter inside a method of a generic class. It returns a PTypeInfo pointer so you can use PTypeInfo(TypeInfo(T))^ record to determine the data type (Kind) -and other attributes- of the generic type. For the lack of generic procedures, you can substitute a generic procedure with a generic class method: type generic TStreamerT = class public procedure StreamType( Stream : TStream; Data : T ); end; procedure TStreamer.StreamType( Stream : TStream; Data : T ); begin case PTypeInfo(TypeInfo(Data))^.Kind of tkString: ... tkInteger: .. end; end; HTH Constantine. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross compiling x86_64 on i386 Linux.
Bruce Tulloch wrote on Tue, 29 May 2012: Closer, but not quite there yet... [...] fpcfixes_2.6/cross/buildcrossbinutils Try adding --with-sysroot to the configure flags in that script. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Streaming of Generics
On Tue, May 29, 2012 at 10:40 AM, kyan alfasud...@gmail.com wrote: Ideally, I'd only like to write the streaming mechanism for each set of types (normal, anisstring, dynamic array, objects, interfaced objects) once, and use it for every set of items. However, there's no reasonable way to detect the type and do an execution for it. Ideally You can use the magic function TypeInfo() to detect the type of a generic parameter inside a method of a generic class. It returns a PTypeInfo pointer so you can use PTypeInfo(TypeInfo(T))^ record to determine the data type (Kind) -and other attributes- of the generic type. Seems TypeInfo is the only reasonable way. Somehow function overloading is resolved before Generic type substitution so that won't work. The set of generic classes is very basic, so speed is up the essence (no variants). I did manage to create a TStream helper, with the following prototypes procedure ReadTyped( Ptr : Pointer; Size : Integer; Typ : PTypeInfo ); procedure WriteTyped( Ptr : Pointer; Size : Integer; Typ : PTypeInfo ); Surprisingly, trying to wrap it up nicely into procedure ReadTyped( var Data ); ... doesn't work because TypeInfo is lost (tkUnknown). -- regards, Kornel Kisielewicz http://chaosforge.org/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error in x32 compiler when using SSE3
OBones wrote on Mon, 28 May 2012: Boy, I'm having a hard day and I'm very sorry to make you waste so much time. Frac was here to see the impact of some changes on the issue, but the original code that crashes is with Trunc instead of Frac so that the comparison looks like this: if Trunc(current/NS.VARIABLE) = current/NS.VARIABLE then Once again, sorry for all the troubles. Ok, please file a bug report so it won't be forgotten. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error in x32 compiler when using SSE3
Jonas Maebe wrote: OBones wrote on Mon, 28 May 2012: Boy, I'm having a hard day and I'm very sorry to make you waste so much time. Frac was here to see the impact of some changes on the issue, but the original code that crashes is with Trunc instead of Frac so that the comparison looks like this: if Trunc(current/NS.VARIABLE) = current/NS.VARIABLE then Once again, sorry for all the troubles. Ok, please file a bug report so it won't be forgotten. Done: http://bugs.freepascal.org/view.php?id=22150 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: I need an lNet expert: multiple connections and only one central CallAction() - is this possible?
On 28.05.2012 16:02, Bernd wrote: What I would have expected would be some API where I can register all these connections (outgoing connections, listening sockets, etc) and then have only one thread blocking in only one call that will watch all these objects at once, but I can't find any explanation how this is supposed to be done with lNet. I can now answer my own question: It seems it is meant to be used in the following way. The first thing I have to do is to have my own instance of a TLEventer class: FEventer: TLEventer; and instantiate it: FEventer := BestEventerClass.Create; and then set a short timeout (1000ms or so) to make the eventer blocking but still be able to check the termination of the thread in regular intervals and create a thread that calls CallAction in an infinite loop: procedure TEventerThread.Execute; begin FEventer.TimeOut := 1000; repeat FEventer.CallAction; until Terminated; end; And then I can create as many TLTcp instances as I need and for every such TLTcp the first thing after creation is to set the Eventer property: FLnetListener := TLTcp.Create(self); with FLnetListener do begin Eventer := FEventer; OnAccept := @OnListenerAccept; FLnetListener.Listen(FListenPort); end; and even more such objects for outgoing connections (one for each connection), each setting the Eventer to the same one and only eventer instance: constructor TBuddy.Create(AClient: IClient); inherited Create; FClient := AClient; FLnetClient := TLTcp.Create(nil); FLNetClient.Eventer := AClient.Eventer; ... end; procedure TBuddy.InitiateConnect; begin with FLnetClient do begin OnConnect := @Self.OnProxyConnect; OnReceive := @Self.OnProxyReceive; OnDisconnect := @Self.OnProxyDisconect; OnError := @Self.OnProxyError; end; FLnetClient.Connect(FClient.TorHost, FClient.TorPort); end; Seems to work quite well, I only have to find out how to properly shut down incoming connections that were disconnected by the other side and then start rapidly firing recv events with 0 bytes (CPU goes 100%), the only way seems to be to set the Dispose property of the TLHandle to true once I receive 0 bytes for the first time on this connection and then pretend the connection is closed but I am not sure if this is allowed and I am not leaking OS handles that way. Also with my code I seem to be able to produce strange crashes inside heaptrc that I have never seen before, still investigating how to reproduce. Bernd ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Streaming of Generics
Am 29.05.2012 12:24, schrieb Kornel Kisielewicz: On Tue, May 29, 2012 at 10:40 AM, kyanalfasud...@gmail.com wrote: Ideally, I'd only like to write the streaming mechanism for each set of types (normal, anisstring, dynamic array, objects, interfaced objects) once, and use it for every set of items. However, there's no reasonable way to detect the type and do an execution for it. Ideally You can use the magic function TypeInfo() to detect the type of a generic parameter inside a method of a generic class. It returns a PTypeInfo pointer so you can use PTypeInfo(TypeInfo(T))^ record to determine the data type (Kind) -and other attributes- of the generic type. Seems TypeInfo is the only reasonable way. Somehow function overloading is resolved before Generic type substitution so that won't work. The set of generic classes is very basic, so speed is up the essence (no variants). I did manage to create a TStream helper, with the following prototypes procedure ReadTyped( Ptr : Pointer; Size : Integer; Typ : PTypeInfo ); procedure WriteTyped( Ptr : Pointer; Size : Integer; Typ : PTypeInfo ); Surprisingly, trying to wrap it up nicely into procedure ReadTyped( var Data ); ... doesn't work because TypeInfo is lost (tkUnknown). This isn't surprising, as TypeInfo resolves the type at compile time based on the expression you give it, but var Data has no type, thus tkUnknown. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
On 29.05.2012 10:25, Rainer Stratmann wrote: I will try later. Also make sure you have turned *off* all optimizations, they can sometimes mess up the stack trace badly (by removing unneeded stack frames which can produce very confusing results) and also I have witnessed at least one occasion where smart linking also somehow interfered with debugging (but this might have been a gdb problem), but maybe better turn this off also, just to be on the safe side. Building your own compiler and RTL from source with debugging symbols only sounds complicated the very first time you hear about this idea, once you have successfully done it yourself you will find that it is actually quite easy and not more complicated than installing a compiler via the .deb packages. Bernd ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] clarification about StackBottom and StackLength in threaded programs and/or shared libraries
Hey, guys. I hate to crosspost but nobody answered me in fpc-devel so
I thought I'd try it here.
Here's my original email from
http://lists.freepascal.org/lists/fpc-devel/2012-May/028965.html
I've got a system which consists of a main program and a few shared
object libraries running under Linux. In a debugging routine I have, I
walk the stack and use BackTraceStrFunc to output the backtrace. The
code I use to do this I adopted from heaptrc.pp, which looks like
this:
===
{ retrieve backtrace info }
bp:=get_caller_frame(get_frame);
{ valid bp? }
if (bp=StackBottom) and (bp(StackBottom + StackLength)) then
for i:=1 to tracesize do
begin
pp^.calls[i]:=get_caller_addr(bp);
oldbp:=bp;
bp:=get_caller_frame(bp);
if (bpoldbp) or (bp(StackBottom + StackLength)) then
break;
end;
===
However, I've found that in my .so, when the backtrace function runs
in the context of a new thread I've started up, sometimes I end up
breaking out of the for loop too soon, because of the
(bp(StackBottom + StackLength)) check. If I pad the comparand on
the right hand side the equation (ie., testing bp(StackBottom +
StackLength + 12 kilobytes or so)), then I get the full backtrace (and
the loop breaks out because (bpoldbp) rather than the second
comparision, which is how I think it should generally be.
How it appears to me is that in thread.inc's InitThread, when
StackBottom is calculated it takes esp and subtracks StackLength. The
thing is, at the time this is run, we're really not the first thing in
the backtrace, so StackBottom is not actually precisely the stack
bottom.
I read a few threads on the mailing list archives (Stack checking in
dynamic libraries and Heap, Stack, HeapTrc and threads) which seem
to touch on this issue, but I wanted clarification on one thing:
Jonas, in this message
(http://lists.freepascal.org/lists/fpc-pascal/2009-November/023040.html)
you said And keep in mind that it's only an approximation when
referring to doing stack checking in dynamic libraries. Is the
calculation of StackBottom the approximation you're referring to? If
that is the case, is what I'm doing (checking bp(StackBottom +
StackLength + someArbitraryPadICameUpWith)) the right thing to do, or
is there a better way to know when to stop walking the stack? Also,
doesn't this mean that since heaptrc does the same thing, it's going
to not necessarily get the entire backtrace (although tracesize would
limit it anyway)?
Thanks,
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: I need an lNet expert: multiple connections and only one central CallAction() - is this possible?
2012/5/29 Bernd Kreuss prof7...@googlemail.com: Also with my code I seem to be able to produce strange crashes inside heaptrc that I have never seen before. Here it is again: Marked memory at $ACBCEC60 invalid Wrong signature $ instead of F1283A25 $015D75BD FINISH_HEAP_FREE_TODO_LIST, line 425 of ../inc/heaptrc.pp $015D75F0 TRY_FINISH_HEAP_FREE_TODO_LIST, line 434 of ../inc/heaptrc.pp $015CCAB2 GETMEM, line 251 of /home/bernd/lazsvn/fixes_2_6/rtl/inc/heap.inc $0164E362 TTEMPLIST__GETENUMERATOR, line 127 of /home/bernd/proj/git_torchat_laz/src/client/tc_templist.pas $0164DE59 TTEMPLIST__CHECKSTATE, line 82 of /home/bernd/proj/git_torchat_laz/src/client/tc_templist.pas $0161535A TTORCHATCLIENT__PUMP, line 220 of /home/bernd/proj/git_torchat_laz/src/client/tc_client.pas $015B7FEE CB_PURPLE_TIMER, line 136 of purpletorchat.lpr $00AE992F Marked memory at $ACBCEC60 invalid Wrong signature $ instead of F1283A25 $015D75BD $015D8B6A $015D75BD $015D75F0 $015CCAB2 $0164E362 $0164DE59 $0161535A $015B7FEE and then it is frozen. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: I need an lNet expert: multiple connections and only one central CallAction() - is this possible?
On 29 May 2012, at 21:31, Bernd wrote: 2012/5/29 Bernd Kreuss prof7...@googlemail.com: Also with my code I seem to be able to produce strange crashes inside heaptrc that I have never seen before. Here it is again: It means that you have memory corruption in your program (using objects after freeing them, writing via pointers that have already been freed, writing past end of a memory block allocated to a pointer, etc). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross compiling x86_64 on i386 Linux.
Hi Tony, I use Debian as my Debian derived distro :-) I agree a minimal chroot environment for each target is a good solution but it's predicated on running a 64-bit kernel on the host (which I am trying to avoid so I can use this setup on a 32-bit capable netbook). Looks like I might have to abandon the idea (cross compiling for a x86_64 target on a i386 host) and upgrade my mobile development platform to something with an x86_64 capable CPU in it :-/ I'll see if Jonas has any more ideas. Cheers, Bruce. On 29/05/12 18:40, Tony Whyman wrote: Bruce, If you are using a Debian derived distribution such as Ubuntu, you might find it easier to use debootstrap to create a 64 bit environment on your system and compile the program in that environment (see https://help.ubuntu.com/community/DebootstrapChroot for a guide). Then you can be sure that you have all the correct libraries in their standard paths, etc. In my set up, I compile for both 64 bit and 32 bit targets on a 64 bit machine and have separate debootstrap (chroots) for each target environment rather than compile in the development environment. This ensures that the final compilation takes place in a known clean environment. I also have a chroot for a win32 cross compiler. Once you have created the chroot for each target, all you need to do is to install the fpc debs in the appropriate environment (64 bit fpc for the 64 bit environment, 32 bit for the 32 bit environment), install any other libraries you need for the distribution repository and then compile the software in each chroot separately. The result will be executables built for each target and built in a clean environment. If you also want to generate distribution packages (debs), this is also the best way to go about it. Regards Tony Whyman MWA Software On 29/05/12 03:19, Bruce Tulloch wrote: Closer, but not quite there yet... To get this going I've (sshfs) mounted a 64 bit system on /mnt/engels and then attempted to cross-compile on the 32 bit system with: fpc -MDelphi -Scgi -CX -O3 -OoUNCERTAIN -OoREGVAR \ -Tlinux -Px86_64 -Xs -XX -va -l \ -dLCL -dLCLgtk2 -XR/mnt/engels This compiles but fails at the linker: Searching file /mnt/engels/usr/lib64/crtn.o... found Searching file /usr/local/opt/binutils/bin/x86_64-linux-ld... found Using util /usr/local/opt/binutils/bin/x86_64-linux-ld /usr/local/opt/binutils/bin/x86_64-linux-ld: skipping incompatible /lib/libpthread.so.0 when searching for /lib/libpthread.so.0 /usr/local/opt/binutils/bin/x86_64-linux-ld: cannot find /lib/libpthread.so.0 Error: Error while linking Fatal: There were 1 errors compiling module, stopping The linker /usr/local/opt/binutils/bin/x86_64-linux-ld was created using (an appropriately modified) fpcfixes_2.6/cross/buildcrossbinutils i.e. built to run on i386 and target x86_64 MYINTEL=i386 TARGETS_X86_64=linux and the pthread library is (presumably, given the -XR option) /mnt/engels/lib/libpthread.so which file reports as libpthread-2.11.3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped How can I find out why x86_64-linux-ld reports it as incompatible? Many thanks, Bruce. On 05/28/12 23:02, Jonas Maebe wrote: On 28 May 2012, at 14:56, Bruce Tulloch wrote: Am I correct to assume that if I drag in the x86_64 libraries I need from another x86_64 system, put them in a local directory and then reference then using the -XR option I can make this setup work? -XR is for pointing the compiler/linker to the top of a complete sysroot (i.e., a hierarchy with /lib, /usr/lib etc), not to a directory with just few handpicked libraries. For the latter, use the -Fl command line switch instead, possibly combined with -Xd (to prevent the compiler from passing the default system directories as search paths to the linker). And yes, that should indeed work fine. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross compiling x86_64 on i386 Linux.
Thanks Jonas, I tried --with-sysroot for configure in buildcrossbinutils and it does not appear to make any difference. I still get the error /usr/local/opt/binutils/bin/x86_64-linux-ld: skipping incompatible /lib/libpthread.so.0 when searching for /lib/libpthread.so.0 at the link phase. I'm thinking that ld should be looking at: /mnt/engels/lib/libpthread.so.0 but according to the error message it's looking at: /lib/libpthread.so.0 which read literally would explain the error. FWIW I have attached the buildcrossbinutils build log in case there's a clue in there. Unless you have any other suggestions I might just give up and upgrade my mobile development environment to an x86_64 capable netbook and run a mixed 64/32 bit system to build 64 bit (and 32 bit) targets. I'm guessing not many people attempt to do it the other way around these days so I might as well join the 64 bit party... Cheers, Bruce. On 29/05/12 18:45, Jonas Maebe wrote: Bruce Tulloch wrote on Tue, 29 May 2012: Closer, but not quite there yet... [...] fpcfixes_2.6/cross/buildcrossbinutils Try adding --with-sysroot to the configure flags in that script. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal log-x86_64-linux.gz Description: application/gzip ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
