beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
corecheckno has joined #picolisp
<tankf33der> hi all
<tankf33der> I am ready and would like to test s390x again, even though I will be busier today than tomorrow. Shall we proceed?
<abu[7]> I'm busy too, but we can proceed at low priority
<tankf33der> installing then
<tankf33der> i will take a time.
<abu[7]> 👍
<tankf33der> installed-compiled
<tankf33der> i know two issues:
<tankf33der> i know two issues (so far):
<abu[7]> ok
<abu[7]> first is the old shared lib issue
<abu[7]> second again a stack issue
<abu[7]> Stack overflow is detected when the 070707070707 markers are destroyed
<tankf33der> I am sure we will learn something new when we get to it.
<abu[7]> so perhaps related to yesterday's stuff
<abu[7]> Which CPU?
<tankf33der> Big endian, platform s390x
<abu[7]> Like yesterday, someone overwrites the stack
<abu[7]> A problem of LLVM backend
<abu[7]> The first problem is a linker issue, not of compiled code
<tankf33der> sure
<abu[7]> I don't know s390x assembly
<abu[7]> won't work like yesterday
<tankf33der> latest 19.1.7. the same
<abu[7]> There is an answer at github
<abu[7]> wrong imho
<tankf33der> where ?
<abu[7]> It mixes what stackrestore does physically (just set the pointer) with how it *might* be used in an ABI (switch between stack frames)
<abu[7]> "Hello. In the PowerPC ABI for C code ..."
<abu[7]> *We* are below the ABI
<abu[7]> we are on machine level
<abu[7]> stackrestore should never mess with the location where SP points to
<abu[7]> Seems they have only *resizing* stack frames in mind
<abu[7]> This is a bad assumption
<tankf33der> pil + issues fixing by changeing O2 -> O0 in opt
<abu[7]> on ppc?
<tankf33der> this is s390x
<tankf33der> on ppc this trick did not help
<abu[7]> The stack overflow issue?
<tankf33der> no
<abu[7]> I mean, overflow issue is fixed on s390x when usinp -O0 ?
<tankf33der> did not fixed
<tankf33der> stay
<abu[7]> What were the "pil + issues" then?
<abu[7]> a third issue?
<tankf33der> first issue from list
<tankf33der> fixed by changing opt -O2 to -O0
<tankf33der> first issue fixed.
<abu[7]> ah
<abu[7]> interesting
<tankf33der> clang -fno-omit-frame-pointer did not helped
<tankf33der> with co issue
<abu[7]> ok
<abu[7]> like in ppc
<abu[7]> Will you answer in github?
<abu[7]> That we are not using the C ABI
<abu[7]> we talk about llvm-ir -> asm
<abu[7]> He is correct with " If you are moving %r1 to an existing frame, then I would expect LLVM to refrain from overwriting the pointer at 0(%r1)"
<tankf33der> afk.
<abu[7]> ok
<tankf33der> Still in shop
<tankf33der> thinking what to comment on github
<abu[7]> I would say that we are not using the C ABI, but the problem is in how the backend transforms LLVM-IR to Ppc64 assembly
<tankf33der> Ok. Asap
<tankf33der> ret
<tankf33der> commented.
<abu[7]> Good! What is Tier1 platform?
<tankf33der> x64 and x86
<tankf33der> maybe aarch64 will be tier1 soon
<abu[7]> I see
elnegro has joined #picolisp
elnegro has quit []
aw- has quit [Ping timeout: 265 seconds]
aw- has joined #picolisp
ygrek has joined #picolisp
ygrek has quit [Remote host closed the connection]
ygrek has joined #picolisp
ygrek has quit [Remote host closed the connection]