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
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
<tankf33der> morning
<tankf33der> checked llvm15-19. the same.
<tankf33der> installed debian on ppc64le. will try.
<tankf33der> debian the same.
rob_w has joined #picolisp
<abu[7]> Sorry tankf33der, I did not look here yesterday any more
<abu[7]> Must be something special in the PPC ABI
<tankf33der> I checked ppc64le port of llvm-nightly. Not available.
<tankf33der> Latest 19.1.7 also failed.
<abu[7]> ok
<abu[7]> Something in the PPC architecture does not map to the LLVM model of PicoLisp
<abu[7]> Pil64 worked though
<abu[7]> I'll check what src64/arch/ppc64* did
<abu[7]> It also used little endian
<tankf33der> I will post list of available cpu festures of llc asap
<abu[7]> good
<tankf33der> I came up with an idea to write a script that will check the work of the LLC for each feature to identify or rule out that the issue lies in the LLC.
<abu[7]> I think it must be something with the stack, speciality of coroutines
<abu[7]> many options
<abu[7]> I think we should first find out *where* exactly it crashes in 'co'
<abu[7]> gdb
<tankf33der> on x64 platform it always returned correct addresses and symbols
<tankf33der> here i never seen ones
<abu[7]> who is "it"?
<tankf33der> picolisp binary
<tankf33der> in gdb
<abu[7]> ok
<abu[7]> "-g" or so at compile time?
<tankf33der> of course i tried
<tankf33der> and no omit pointers
<abu[7]> ok
<tankf33der> i always seen question marks in gdb
<tankf33der> and strip ommited
<abu[7]> yeah, no symbols
<tankf33der> trying debian's gdb
<tankf33der> the same
<tankf33der> llvm14 the same
<tankf33der> probably problem with gdb becase i am inside docker+qemu under x64 machine
<tankf33der> this is not a real hardware
<abu[7]> I see
<tankf33der> i give up
<abu[7]> Hmm
<abu[7]> How about inserting 'dbg' calls into 'co'? That's how I debug PilSrc code, I never used gdb
<tankf33der> provide steps
<tankf33der> i do not remember details
<abu[7]> OK, let me prepare
<abu[7]> It fails with (co 'a 7) ?
<tankf33der> yes
<abu[7]> kind of minimal co
<abu[7]> Please change '_Co' in @src/flow.l to http://pb1n.de/?9da5b5
<tankf33der> trying
<abu[7]> Then compile and do
<abu[7]> : (co 'a 7)
<tankf33der> # ../bin/picolisp
<tankf33der> 1 a
<tankf33der> 3 a
<tankf33der> : (co 'a 7)
<tankf33der> 4 (7)
<tankf33der> Segmentation fault (core dumped)
<abu[7]> good
<abu[7]> So it crashes in (let Main: (coroutine
<abu[7]> Earlier than I expected ;)
<abu[7]> Next try http://pb1n.de/?50311f
<tankf33der> root@0e3b70296297:~/pil21/src# ../bin/picolisp
<tankf33der> : (co 'a 7)
<tankf33der> 2
<tankf33der> 3
<tankf33der> 1 T
<tankf33der> 4
<tankf33der> 5
<tankf33der> Segmentation fault (core dumped)
<abu[7]> So it is (memset ..)
<abu[7]> thinking ...
<abu[7]> Let's test only the 'stack' call http://pb1n.de/?50311f
<abu[7]> wait
<taleon> Is it possible to analyze the core dump with ktrace or other utilities?
<abu[7]> wronp
<abu[7]> This one http://pb1n.de/?50ae0e
<tankf33der> doing
<abu[7]> Hi taleon!
<abu[7]> not sure
<taleon> Hi :)
<abu[7]> ktrace tracks system calls only?
<taleon> ktrace /usr/bin/pil
<tankf33der> root@0e3b70296297:~/pil21/src# ../bin/picolisp
<tankf33der> : (co 'a 7)
<tankf33der> 1 T
<tankf33der> Segmentation fault (core dumped)
<tankf33der> 2
<taleon> kdump -f ktrace.out > pil.kdump
<taleon> You can then analyze the kdump with a text editor.
<abu[7]> ok, (stack) on the same address works
<abu[7]> taleon, does it track machine instructions?
<taleon> Not sure if ktrace only tracks system calls. I used it to find and fix Branch Target Identification (BTI).
<abu[7]> tankf33der, now change (stack Stk) to (stack (- Stk 10000))
<abu[7]> ie. try to actually decrement the stack pointer
<abu[7]> We now have (dbg 1 $T) (stack (- Stk 10000)) (dbg 2 0)
<tankf33der> root@0e3b70296297:~/pil21/src# ../bin/picolisp
<tankf33der> : (co 'a 7)
<tankf33der> 2
<tankf33der> 1 T
<tankf33der> Segmentation fault (core dumped)
<abu[7]> oh
<abu[7]> decrement works
<abu[7]> so it is indeed the memset
<tankf33der> afk in 30min
<abu[7]> ok
<abu[7]> Seems we are not allowed to write into the allocated stack segment
<abu[7]> not yet allocated
<abu[7]> it is *below* current SP
<abu[7]> this may be illegal
<abu[7]> no, I'm wrong
<abu[7]> (stack (ofs Stk (- Siz))) temporarily decrements SP
<abu[7]> should be legal
<abu[7]> Let me think more and continue when tankf33der is back
<abu[7]> tankf33der: When back, please post the file @src/picolisp.s which was generated in our last test
<tankf33der> ret
<abu[7]> to see how exactly the stack is manipulated on PPC
<tankf33der> thinking how to cut file from image
<abu[7]> cut?
<tankf33der> i am in docker+qemu
<abu[7]> ah
<abu[7]> pb1n from qemu?
<tankf33der> doing
<tankf33der> damn
<tankf33der> 256KB file protection on pb1n,
<tankf33der> 256KB file protection on pb1n
<tankf33der> :)
<abu[7]> hmm, then just a part of the file
<abu[7]> Search for ^_Co
<abu[7]> no
<abu[7]> ^_Co:
<abu[7]> this is the start of 'co'
<tankf33der> try
<abu[7]> Looks good!
<tankf33der> this is from alpine linux with configured ip
<abu[7]> perfect
<tankf33der> meeting after 15min. maybe delays
<abu[7]> ok
<abu[7]> I investigate
<abu[7]> stack pointer is register 1 on ppc
<tankf33der> afk
<abu[7]> I think I found the problematic point
<abu[7]> ok, later
<abu[7]> It is "ld 3, 0(1)"
<abu[7]> PPC uses the top of stack for temp storame
<abu[7]> storage
<abu[7]> We can try a workaround later
<abu[7]> a safety space of 8 bytes perhaps
rob_w has quit [Remote host closed the connection]
<tankf33der> ret
<abu[7]> There are 3 places
<tankf33der> all from co
<tankf33der> ?
<abu[7]> 2 from co, one in 'stack'
<tankf33der> ok
<tankf33der> At this pace, and while you're warmed up, maybe you'll want to look into the issues with s390x afterward? :)
<abu[7]> ok, let's see
<abu[7]> I think I have a fix
<abu[7]> I reserve a safety space of 8 bytes on the stack
<abu[7]> not needed for x86 or Arm etc
<abu[7]> But who knows if other CPUs also have that issue?
<tankf33der> i can test as wide as possible
<abu[7]> great
<tankf33der> now picolisp works on alpine: aarch64, loongarch64, x86_64
<tankf33der> ppc64le-s390x-riscv64 is the queue
<abu[7]> I made a temporary release:
<abu[7]> app@7fach.de:pub/pil21.tgz
<abu[7]> Can you try that?
<tankf33der> is that maxtrix ?
<taleon> Well done and very good. :-)
<abu[7]> taleon, not sure yet :)
<abu[7]> It is my comany's server
<abu[7]> same as picolisp.com btw
<tankf33der> abu[7]: how to get this?
<abu[7]> so you can use app@picolisp.com/pub/pil21.tgz
<abu[7]> curl -O app@picolisp.com/pub/pil21.tgz
<tankf33der> ok. works.
<taleon> I even still have a Lemote Yeeloong 8101B with loongson architecture. Not sure if that's loongarch64, though.
<abu[7]> uh
<abu[7]> never heard of
<tankf33der> abu[7]: crashed
<tankf33der> on (co 'a 7)
<abu[7]> oh
<abu[7]> :(
<tankf33der> i can send you a .s file
<abu[7]> no
<abu[7]> the old one is ok
<abu[7]> can you change (stack (- Lim 8)) in line 1211 ?
<abu[7]> 8 to perhaps 32 ?
<tankf33der> what file ?
<abu[7]> Same in line 1150
<abu[7]> _Co
<abu[7]> @src/flow.l
<tankf33der> works.
<abu[7]> But still I think 8 should be enough
<abu[7]> Moment
<tankf33der> complex examples failed without crash
<abu[7]> What if you use 16
<tankf33der> crash
<tankf33der> on (co 'a 7)
<abu[7]> hmm
<abu[7]> Let's continue later, I must go now
<tankf33der> oki
<abu[7]> I think more about it
<abu[7]> Thanks so far!
<abu[7]> Forget the above version. I did not yet understand the issue
<abu[7]> ppc is picky about the stack
<abu[7]> It does not notice that it just set the stack to another value
<abu[7]> I must study PPC (again after many years)
<tankf33der> No hurry. Should be easy for you then
<abu[7]> Not at all
<abu[7]> perhaps unsolvable
<abu[7]> if we don't find a way to stop ppc doing that
<tankf33der> stack align is 16 bytes. right ?
<tankf33der> to stop llvm doing what on ppc ?
<abu[7]> Not surs, 8 byte align would be ok
<abu[7]> PilStc controls it
<tankf33der> LLM sais stack align is 16
<tankf33der> i checked in two different models
<abu[7]> OK
<abu[7]> But the problem is that LLVM on PPC doen not handle changed stack pointer correctly, it seems
<tankf33der> ok
<abu[7]> I just came home
<abu[7]> searching the web
<tankf33der> clang --help | grep stack
<abu[7]> Most options are not clear to me
<tankf33der> the same
<abu[7]> Google did not help
<tankf33der> chatgpt ?
<abu[7]> I use Perplexity
<tankf33der> good
<abu[7]> but hard to find the precise question
<tankf33der> what did you search ?
<abu[7]> LLVM PowerPC stackrestore
<abu[7]> stackrestore is the llvm-ir instruction
<abu[7]> But I still don't understand what *exactly* is wrog
<abu[7]> wrong
<abu[7]> in your .s file it writes to and reads from 0(1)
beneroth has joined #picolisp
<abu[7]> 1 is the stack pointer
<abu[7]> ld 3, 0(1) mr 1, 21 std 3, 0(1)
<abu[7]> makes no sense to me
<abu[7]> mr 1, 21 changes the SP
<abu[7]> But why does it write to that location?
<abu[7]> It is overwritten then by memset
<abu[7]> and BANG
<abu[7]> I don't know what exactly to ask
<tankf33der> #ppc64 ?
<abu[7]> No idea
<tankf33der> it exists
<abu[7]> No precise question
<abu[7]> I give up
<abu[7]> revert the change
<bjorkintosh> tankf33der: what system is using ppc?
<tankf33der> ibm power8-10
<bjorkintosh> interesante.
<bjorkintosh> how did you get it?
<tankf33der> in docker+qemu :)
<bjorkintosh> ah. so it's a for exercising picolisp then?
<tankf33der> but i have several power7-8 in data room
<tankf33der> yeap
<tankf33der> afk
<abu[7]> Now I asked Perplexity
<bjorkintosh> are you more perplexed?
<abu[7]> To my surprise not
<abu[7]> gave a reasonable answer
<abu[7]> I dig into it
<abu[7]> Seems indeed a bug in the LLVM backend, but no real solution: http://pb1n.de/?8b5097
<bjorkintosh> picolisp is safe.
<abu[7]> T
<tankf33der> Ask him github issue number
<abu[7]> It did not give a link to an issue
<abu[7]> Above I inserted only the first two links
<abu[7]> Not clear
<abu[7]> This is the whole query:
<abu[7]> The proposed solutions seem all to involve fixing the LLVM/PowerPC backend code (.cpp stuff)
<abu[7]> I give up ;)
<tankf33der> Sad alpine have no llvm-next ports
<tankf33der> ok
<abu[7]> What is llvm-next ?
<tankf33der> every system have their own name systems
<tankf33der> some named llvm-devel
<tankf33der> nightly snapshots of llvm
<tankf33der> some llvm20 or llvm-20
<tankf33der> let me check ppc issues on github
<abu[7]> understand
<tankf33der> 88 opened, reading
<abu[7]> uh
<tankf33der> with text 'stack' in subject 18 issues
<tankf33der> from 88
<abu[7]> Problem is llvm.stackrestore() I think
<tankf33der> 0
<abu[7]> Yeah, a very exotic problem
<abu[7]> Most langs don't use it
<abu[7]> I need for coroutines
<abu[7]> but which langs have coroutines?
<tankf33der> i very wanted repeat chacha20 stress test like i did in picolisp, but did find languages with such a features picolisp has
<tankf33der> abu[7]: check this one
<abu[7]> grr, I hate github! "gzip: stdin: not in gzip format" in w3m
<abu[7]> ... viewing in PilBox then
<tankf33der> thank you.
<tankf33der> if this is it, then i will subscribe and update picolisp port in alpine
<abu[7]> Since today also Google search doesn't work in w3m any more
<abu[7]> needs JS
<abu[7]> I saw this one too this afternoon
<abu[7]> similar
<abu[7]> but a different problem
<abu[7]> At least no llvm.stackrestore()
<tankf33der> hard to open new issue then
<abu[7]> yeah
<tankf33der> what if you write small llvm-ir code and it will be wrong, just for example
<abu[7]> Hard to say what is really wrong
<abu[7]> I'm not sure if we can say it is wrong if something is written above the stack pointer
<abu[7]> I *believe* it is wrong if just setting the SP triggers a *write* to this location
<abu[7]> yeah, must be wrong
<abu[7]> as far as I understood APIs until now
<tankf33der> the simplest
<abu[7]> quite simple, doen not need two arrays
<tankf33der> :)
<abu[7]> Optimized away?
<tankf33der> llc errcode.ll -o errcode.s
<tankf33der> unknown.
<abu[7]> stackrestore is something like "mr 1, 3"
<abu[7]> move to register 1
<tankf33der> yes
<abu[7]> Not in the .s
<tankf33der> yeah
<abu[7]> stackrestore at the end of a fun is a no-op
<abu[7]> thus removed
<tankf33der> i opening llvm issue
<tankf33der> fingers crossed
<abu[7]> great :)
<tankf33der> btw
<tankf33der> what if remove std line from picolisp.s
<tankf33der> is it possible?
<abu[7]> Basically yes, but the code stores a value there, which is then lost
<abu[7]> I think the code wants to store in the original stack frame
<abu[7]> but SP changed
<abu[7]> btw
<abu[7]> is there by default a frame pointer omitted?
<tankf33der> unknown
<tankf33der> i tried a lot of parametrs
<abu[7]> gcc had something like --omit-frame-ptr
<abu[7]> if frame pointers are omitted, all is done via stack pointer
<tankf33der> clang has:
<tankf33der> -fomit-frame-pointer Omit the frame pointer from functions that don't need it.
<abu[7]> This could be a fix (though it is still a bug)
<abu[7]> yeah
<abu[7]> can we disable -fomit-frame-pointer ?
<tankf33der> crashed
<abu[7]> we need the opposite
<abu[7]> ieg -fuse-frame-pointer
<tankf33der> clang -O0 -fno-omit-frame-pointer ...
<tankf33der> crashed
<abu[7]> Probably using *not* -fomit-frame-pointer does this
<abu[7]> I see
<tankf33der> picolisp.s
<abu[7]> Not sure, something is wrong anyway
<tankf33der> check again if possible remove std line
<abu[7]> std 5, 0(1)
<abu[7]> still has it
<tankf33der> i do not have this line
<tankf33der> hm
<abu[7]> search ^_Co:
<abu[7]> then "memset"
<abu[7]> the lines before memset
<abu[7]> line 33454/103537 in your pb1n
<tankf33der> removed std line and crashed
<abu[7]> T
<abu[7]> you can't remove
<abu[7]> the value is *read* back later
<abu[7]> That's why we had a pointer 070707070707
<abu[7]> your first error report
<abu[7]> memset writes 070707070707 into the whole stack frame
<abu[7]> And std stored something
<abu[7]> which is later retrieved but destroyed
<abu[7]> The std *wants* to write to the original sp
<abu[7]> but sp changed
<abu[7]> so the write goes wrong
<abu[7]> IMHO the LLVM backend doen not notice that it just changed SP
<abu[7]> s/doen/does
<abu[7]> Good
<abu[7]> Let's hope there is somebody who understands it
<abu[7]> Nuff for today
<tankf33der> afk
<abu[7]> Thanks for all the input!
<abu[7]> o/
knlb has joined #picolisp
knlb has quit [Remote host closed the connection]
Serj-Aleks has joined #picolisp
Serj-Aleks has quit [Client Quit]