Hi again! Am Montag, den 12.05.2014, 23:33 +0200 schrieb Johann Glaser: > Hi! > > I'm working on a project with an external library (libtcl, it is written > in C) which creates some problems with back traces for exceptions. > > If a custom TCL command raises an exception, I catch it and use the > function DumpExceptionBackTrace to print the back trace. This function > uses RaiseList which returns the ExceptObjectStack pointer. The stack > frame information is filled by fpc_PushExceptObj in except.inc using the > functions get_frame, get_caller_addr and get_caller_frame. > > These three functions are also used by dump_stack which can be used at > any point in the code (outside of exceptions). > > These three functions assume, that the stack frame is stored in the RBP > register (x86_64 architecture) and that every function call starts with > these two assembler instructions > push %rbp > mov %rsp,%rbp > which leads to the stack layout of the return address (pushed by the > "call" instruction) followed by the RBP value. > > As this is true for FreePascal code (I guess), this doesn't necessarily > hold for external libraries as the TCL library mentioned above.
News on that front: Today I investigated a duplicate key exception in FGL.TFPSMaps.Add(AKey: Pointer): Integer. In the current Debian package fp-units-rtl-2.6.4 2.6.4+dfsg-2 this seems to be compiled with looots of optimization and without stack frame: 0000000000001918 <FGL_TFPSMAP_$__ADD$POINTER$$LONGINT>: 1918: 48 81 ec 18 01 00 00 sub $0x118,%rsp 191f: 48 89 9c 24 08 01 00 mov %rbx,0x108(%rsp) 1926: 00 1927: 4c 89 a4 24 10 01 00 mov %r12,0x110(%rsp) 192e: 00 192f: 48 89 fb mov %rdi,%rbx 1932: 49 89 f4 mov %rsi,%r12 Even GDB couldn't trace back the stack there. :-O Bye Hansi _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel