Hi
On which platform? When I compile the attached tt.pp file with -gw4
-Clfsanitize=address (LLVM 13, Debian 11, x86-64) and then run it, I
get the output in tt.txt. It includes line information.
You could try lldb instead of gdb, although gdb should also be able to
handle debug information generated by LLVM.
Ubuntu 22.04, LLVM 13
Nothing helps.
only some units are affected
Actually, now I see the warnings during compilation
Assembling xquery
mismatched subprogram between llvm.dbg.addr variable and !dbg attachment
inlinable function call in a function with debug info must have a !dbg
location
invoke void
@"\01XQUERY$_$IXQVALUE_$__$$_$finalize$IXQVALUE"(%typ.XQUERY.IXQValue*
%reg.1_200)
to label %.Lj9768 unwind label %.Lj9743
.....
call void @llvm.dbg.addr(metadata %typ.SYSTEM.TRTLCriticalSection*
%tmp.1, metadata !48637, metadata !DIExpression()), !dbg !48773
label %0
void ()* @"\01XQUERY_$$_finalize$"
!48637 = !DILocalVariable(name: "_zero_$SYSTEM_$$_TRTLCRITICALSECTION",
scope: !48635, file: !3, line: 10567, type: !1260)
!48635 = distinct !DISubprogram(name: "XQUERY_$$_init$", scope: !3,
file: !3, line: 3506, type: !7606, scopeLine: 10504, spFlags:
DISPFlagDefinition, unit: !2)
!48773 = !DILocation(line: 10570, column: 1, scope: !48772)
!48772 = distinct !DISubprogram(name: "XQUERY_$$_finalize$", scope: !3,
file: !3, line: 10570, type: !7606, scopeLine: 10570, spFlags:
DISPFlagDefinition, unit: !2)
warning: ignoring invalid debug info in
/home/theo/lib/fpc/x86_64-linux/xquery.ll
The first appears to be caused by my managed operator patch
Then there is the default issue
https://gitlab.com/freepascal.org/fpc/source/-/issues/40395
(and you have fixed it while I was still writing this mail)
Then this:
https://gitlab.com/freepascal.org/fpc/source/-/issues/40280 is causing a
stack corruption
https://gitlab.com/freepascal.org/fpc/source/-/issues/40392 is causing a
heap corruption
Cheers,
Benito
On 11.08.23 12:57, Jonas Maebe via fpc-pascal wrote:
On 10/08/2023 23:27, Benito van der Zander via fpc-pascal wrote:
i tried to run my program under LLVM (from july fpc) and it crashes?
Program received signal SIGSEGV, Segmentation fault.
0x000000000042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER()
(gdb) bt
#0 0x000000000042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER()
#1 0x000000000041b92ain fpc_ansistr_setlength()
#2 0x0000000000558d52in RESETBUFFER(ABUFFER=0x7fffffffd560,
BASECAPACITY=130) at bbutils.pas:1650
#3 INIT(ABUFFER=0x7fffffffd560, BASECAPACITY=130, AENCODING=65001) at
bbutils.pas:1639
#4 STRDECODEHTMLENTITIES(result=0x0, P=<optimized out>, L=130,
ENCODING=65001, FLAGS=...) at bbutils.pas:5527
anyone has seen sysgetmem crash before?
It suggests heap corruption.
Perhaps that is exactly the kind of things ASAN was supposed to detect.
Possibly, yes.
But with ASAN, I get an error somewhere entirely else. And I do not
understand it, because the function is shown as ~ 5000 lines of
assembly.
How can I see the mixed code with disassemble /rm in gdb? I tried to
call fpc -gl, -gs and -gw, and nothing helps
On which platform? When I compile the attached tt.pp file with -gw4
-Clfsanitize=address (LLVM 13, Debian 11, x86-64) and then run it, I
get the output in tt.txt. It includes line information.
You could try lldb instead of gdb, although gdb should also be able to
handle debug information generated by LLVM.
And there are a lot of weird ASAN calls for trivial movs. Like:
0x00000000006f577c<+22204>: 48 8b bb c8 00 00 00
movrdi,QWORDPTR[rbx+0xc8]
0x00000000006f5783<+22211>: e8 18 cc d0 ff
call0x4023a0<__asan_report_load8@plt>
0x00000000006f5788<+22216>: e8 13 cc d0 ff
call0x4023a0<__asan_report_load8@plt>
0x00000000006f578d<+22221>: e8 0e cc d0 ff
call0x4023a0<__asan_report_load8@plt>
0x00000000006f5792<+22226>: e8 09 cc d0 ff
call0x4023a0<__asan_report_load8@plt>
0x00000000006f5797<+22231>: 48 89 c7 movrdi,rax
0x00000000006f579a<+22234>: e8 01 cc d0 ff
call0x4023a0<__asan_report_load8@plt>
0x00000000006f579f<+22239>: 48 89 cf movrdi,rcx
0x00000000006f57a2<+22242>: e8 09 ca d0 ff
call0x4021b0<__asan_report_store8@plt>
Are they supposed to be there?
These are generated by LLVM's own code generator, so yes.
Jonas
_______________________________________________
fpc-pascal maillist -fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
