Wednesday, 2022-06-08

ghostmansdlkcl, for sure I'm familiar with makefile :-)07:32
ghostmansdagain: the assembly generated before and after the changes is identical07:32
ghostmansd[m]lkcl, all mp3_0 tests run fine for me, perhaps I still misinterpret what you want.10:46
ghostmansd[m]For the record, I did not drop how the existing comments are handled.10:46
ghostmansd[m]I only fixed the script to actually convert records like `sv.add X,Y,Z # cocojumbo`10:47
ghostmansdI'm going to clean some commits and start working on 838 then. Any objections?11:11
ghostmansdI'm still waiting for GNU approval, though. I was wondering if we could start committing some small(ish) patches.11:12
lkclghostmansd, brilliant. ok so now, if you change the assembler at the lines i suggested (# sv.xxxx to just sv.xxxx) and simultaneously alter pysvp64asm you can check it works11:38
lkclyou really don't need to run absolutely every single one of the tests though, you can just run one.11:38
lkcllkcl> ./audio/mp3/ 0 /tmp/out011:38
lkclfor extra bonus points11:39
lkcladd a way to use *binutils* to compile the binary and make sure that the binary is identical11:39
ghostmansdlkcl, but it works now, even without changes11:39
ghostmansdI mean, $(make tests) work on master11:40
ghostmansdexcept for mp3_111:40
ghostmansdor do you want me to check that tests work if I uncomment `# sv.` lines?11:40
lkclit works now because pysvp64asm is a hack11:41
lkclbecause of anything with "#" in front of it is *substituted* for ".long NNNN xxxx # sv.xxxx"11:41
lkclhowever we do actually need *binutils* to work11:42
lkclbecause it is making life very difficult for markos that pysvp64asm only has very very rudimentary macro support11:42
lkclso what i'm asking is, now that binutils _can_ actually do the same job, could you alter pysvp64asm so that it no longer needs that hack?11:44
lkclthe *exact same assembler* in the media/ directory *can be compiled with binutils now*11:44
lkcli'm happy to up the amount for 838 to include that11:45
lkclother than that yes go for it on 83811:45
ghostmansdOK, now I got it11:46
ghostmansdall this time I was under impression that I broke something with my commit to openpower-isa11:46
lkclmarkos's task of developing the assembler version of imdct36.c is made difficult11:46
lkcl*if* you had altered pysvp64sim *without* also updating the media/ assembler11:46
lkcl(to remove the hack)11:47
lkcl*then* you would have broken the work that critically depends on it11:47
lkclthat was my biggest concern11:48
lkcli leave it with you? (back later, will keep checking via irclog)11:48
ghostmansdOK I think I understood what's broken11:49
ghostmansdI've been looking at vanilla asm, not SV11:49
ghostmansdOK I'll fix it11:49
ghostmansdand also think about binutils integration11:49
lkclbtw we do need a "build script" for binutils now11:50
lkclVeera[m], are you happy to do that?11:50
lkclghostmansd, if you can help Veera[m] out there, just let him know (in basic form) how to build it with the correct branch11:51
lkclsomething off of as usual, Veera[m] has done this many times now11:52
ghostmansdVeera[m], just ping me when you're ready11:58
ghostmansdlkcl, FWIW, I've submitted RFP for 84412:49
lkclghostmansd, magic. do update the TOML field with the date13:48
lkclcheck with budget-sync that it worked13:49
ghostmansdhm, why does schroot gives "I have no name" on talos?13:54
ghostmansd$(schroot -c ghostmansd /bin/bash)13:56
ghostmansdlkcl, budget-sync seems OK14:02
ghostmansdupdated my page with this info14:04
ghostmansdit seems inside chroot its /etc/passwd is fucked; I have no idea why, so I ended up copying & pasting the /etc/passwd from the talos14:47
ghostmansdalso, the whole chroot jail has lkcl:lkcl as user:group14:52
octaviuslkcl, I updated the pinmux page, but realised I lost my write access to libreriscv repo. Can you grant it again?16:45
lkclghostmansd, edit /etc/passwd and /etc/group manually to fix that.17:28
lkcl(in the chroot i mean of course)17:28
lkcloctavius: done17:29
lkclyou are uid 1006/1007 so just edit /opt/chroot/ghostmansd/etc/passwd to match that17:30
ghostmansdcool story bro!17:32
ghostmansdI failed but still succeeded :-)17:32
lkclyou are 6. number 6.17:35
lkclfuun. ah the joys of starting a compile totally from source/scratch17:37
lkcla trick there, leveraging debian:17:37
lkclapt-get build-dep binutils17:37
lkclthat will recursively install *all* the build dependencies [that debian happens to use] for the package17:37
lkclusually, unless something has gotten horribly out of hand in the development branch of the source-only package, you get all the right/required dependencies17:38
ghostmansdwow it's been a while since I played HL17:39
ghostmansdit's a real gem17:39
ghostmansd> usually, unless something has gotten horribly17:39
ghostmansdI'm inside chroot on talos17:39
ghostmansdI think I already launched hdl-apt-reqs17:40
ghostmansdBut I think I might be confused since I also did it on my debian recently...17:41
ghostmansdfuck Luke17:47
ghostmansdI think I just accidentally launched ./install-hdl-apt-reqs outside of jail17:47
lkclah i wanted to find the theme music for The Prisoner17:47
ghostmansdfuck fuck fuck sorry17:47
lkclkill it17:47
lkclok let's see what it's done17:48
lkclwhere did it get to?17:48
ghostmansdI only realized it when it completed17:48
lkclah :)17:48
lkclprobably for the best to let it complete17:48
lkclok let's see...17:48
ghostmansdI think it changed to backports...17:49
lkclapt-get update and apt-get upgrade.17:49
ghostmansdfuck I'm so sorry17:49
lkclit's ok, it's still running17:49
ghostmansddo you mean there's no damage?17:51
ghostmansdbecause I'm under impression I've "upgraded" stuff to wrong versions17:52
ghostmansdI think I'll make my account chroot on login17:52
lkclyes you have, however everyone should be using schroots on there anyway17:52
lkcljust add an entry into /opt/chroot/etc/debian_chroot17:54
lkclthen when you schroot in, it *should* add that into the bash prompt17:55
lkclso you know the difference17:55
ghostmansdI've been thinking, perhaps you could retract admin rights from anyone but you?18:05
ghostmansdalso, I cannot compile binutils-gdb via dev-env-setup/ppc64-gdb-gcc script; I'll try to build it via usual way18:06
ghostmansdVeera[m], lkcl, I think that it'd be the simplest option to switch dev-env-setup/ppc64-gdb-gcc script to our modified binutils-gdb18:07
ghostmansdI guess problems with dev-env-setup/ppc64-gdb-gcc script come from the fact it uses `--host=x86_64-linux` :-)18:11
ghostmansdperhaps I was the one psycho to add it18:11
ghostmansdhm... $(../configure --srcdir=.. --target=powerpc64-linux-gnu | grep "\-as") yields "checking for powerpc64-linux-gnu-as... no"18:13
ghostmansd$(../configure --srcdir=.. --target=powerpc64le-linux-gnu | grep "\-as") yields "checking for powerpc64le-linux-gnu-as... powerpc64le-linux-gnu-as"18:13
ghostmansdthat said, tests in media/audio use powerpc64-linux-gnu-as, not powerpc64le-linux-gnu, and the script also uses it...18:16
lkclah ha! i had forgotten, we do have binutils-gdb18:22
lkclmedia/audio needs then to be modified to use powerc64le-linux-gnu18:22
lkclyes agreed switch ppc64-gdb-cc to the right branch18:23
ghostmansdVeera[m], ^^^18:26
ghostmansdlkcl, I think I caused fail2ban wrath on talos118:27
ghostmansdforgotten to add entry with Port 922 to ssh for gitolite318:27
ghostmansdhow long does its anger last?18:27
ghostmansdhm, no, it must be something else...18:29
ghostmansdI cannot clone gdb repo from talos18:29
ghostmansdbut, for example, utils is completely fine18:29
ghostmansdfwiw, I cannot clone even from https18:29
ghostmansd$(git clone just hangs18:30
ghostmansdah no ignore it; repo is huge, so it just takes an enormous time on talos118:31
ghostmansdno idea why18:31
lkclyes over HTTPS this does not surprise me18:33
lkclin future you can check progress18:33
lkclby backgrounding the clone18:34
lkclthen doing "du {insert directory name}"18:34
ghostmansderror: RPC failed; curl 56 GnuTLS recv error (-9): Error decoding the received TLS packet.18:34
ghostmansdfetch-pack: unexpected disconnect while reading sideband packet18:34
lkcl"ls -altr {directory name/.git}"18:34
lkcluse the ssh clone18:34
lkcl1 sec...18:34
lkclermermermerm how am i going to do this...18:35
lkcli know18:35
ghostmansdlet me add public key18:35
ghostmansdah wait, it won't be sufficient, right?18:36
ghostmansdsince I need to also have private key on talos1...18:37
lkclyes don't do that am sorting it out for you18:37
ghostmansdah OK18:37
ghostmansdnot that I intended to copy private key lol18:37
lkclwheeee underway18:40
programmerjakewell, ssh does allow you to forward auth info...18:41
lkclok what i've done is, i've created an ec25519 key-pair in /home/ghostmansd/.ssh18:41
lkclprogrammerjake, i forgot about that.  doh :)18:41
lkclbut ahh it has to cross the schroot barrier as well in this case18:41
lkcli then added that key to gitolite318:41
lkcli then *copied* both the private and public key into the chroot homedir18:42
programmerjakessh into the chroot?18:42
lkcland i'm now using it to run git clone for you.18:42
lkclprogrammerjake, that would need an sshd server running inside the chroot18:42
lkclon a high port number18:42
lkcland configured only to accept localhost18:43
lkcli'm done with the extra key pair already18:43
ghostmansd> sshd inside the chroot18:43
ghostmansdlkcl, we need to go deeper18:43
lkcl(ghostmansd)ghostmansd@75-224-155-23:~/src$ git clone
lkclit's already running18:43
programmerjakewell, start one temporarily, should be pretty easy....or maybe just link the ssh-agent socket into the chroot18:43
lkclremote: Compressing objects: 100% (164323/164323), done.18:43
lkclReceiving objects:  74% (731085/987952), 279.24 MiB | 1.64 MiB/s18:43
ghostmansdaha I see18:44
lkclprogrammerjake, ah yeah that would work18:44
lkclbut, hey, it's solved now18:44
lkclResolving deltas:  55% (454281/825964)18:44
ghostmansdyeah I won't commit from talos1 anyway18:44
ghostmansdI mostly want to run tests18:44
lkclyou could in theory18:45
lkclbut if you really don't want to i can remove write-access for that key, you'll at least have read-access18:45
lkclok all done18:45
ghostmansdyes please keep it with RO access18:45
lkcl(ghostmansd)ghostmansd@75-224-155-23:~/src$ ls -altr18:45
lkcldrwxr-xr-x 30 ghostmansd       1007     4096 Jun  8 17:54 binutils-gdb18:45
ghostmansdI'd also be glad if you revoke admin from the user18:45
lkcli can't revoke read-access18:45
ghostmansdI mean simply revoke write access for key18:46
lkclmhrrrmm... make sure sudo in the schroot is possible, first18:46
ghostmansdjust did $(sudo su) inside chroot18:46
lkclno password?18:47
lkclexccellent muhahaah18:47
lkclif you need to make any more schroots i'll need to restore sudo rights for you.18:47
ghostmansdI hope I won't18:47
ghostmansdunless someone as dumb as me will come and launch some scripts outside of chroot :-)18:48
lkcldon't feel limited to just one schroot18:48
lkcli have... eight, i think.18:48
lkclnope, 12.18:48
lkcl$ ls /opt/chroot/18:49
lkclcleansoc         coriolis_714_test  kestrel         symbiflow18:49
lkclcleantest        coriolisnew        nextpnr-xilinx  symbiflow-clean18:49
lkclcoriolis2_clean  isolatedchroot     stretch-i386    test18:49
ghostmansdwhat for?18:49
lkcltesting the work that Veera[m] did on nextpnr-xilinux18:49
lkcland on symbiflow18:49
lkcland on the preliminary work i did on symbiflow18:49
ghostmansdlkcl, programmerjake, a question: do you have both powerpc64le-linux-gnu-as and powerpc64-linux-gnu-as?18:49
lkcland testing coriolis2 updates18:49
lkcland and and and18:49
ghostmansdbecause, well, powerpc64le-linux-gnu provides as, but powerpc64-linux-gnu doesn't18:49
ghostmansdI'd like to switch audio tests to powerpc64le-linux-gnu-as18:50
lkclyep go for it18:50
lkcli have both installed18:50
lkclthey are absolutely no different *at all* other than the default arguments18:50
lkclyou can use powerpc64-linux-gnu with a -le switch18:50
lkclyou can use powerpc64le-linux-gnu with a -be switch18:51
lkcl$ dpkg -l | grep powerpc6418:51
lkclii  binutils-powerpc64-linux-gnu                     2.35.1-7                                amd64        GNU binary utilities, for powerpc64-linux-gnu target18:51
lkclii  binutils-powerpc64le-linux-gnu                   2.35.1-7                                amd64        GNU binary utilities, for powerpc64le-linux-gnu target18:51
lkcli have both18:51
programmerjakeicr, i haven't invoked ppc as in a while, i probably have both though18:56
ghostmansdOK pushed18:57
ghostmansdI'm setting new binutils-gdb inside my chroot, from svp64 branch18:57
programmerjakei currently just use it solely through the openpower tests18:57
ghostmansdI'd like to ensure things work18:57
ghostmansdsv.fmuls fv0.v, fv0.v, fv1.v19:21
ghostmansd.set fv0, 3219:21
ghostmansd.set fv1, 4019:21
ghostmansd.set fv2, 4819:21
ghostmansdsv.fmuls fv0.v, fv0.v, fv1.v19:21
ghostmansdlkcl, programmerjake, I don't think it's gonna work... or should it?19:21
lkclghostmansd, yyyep!19:34
lkclbecause of the binutils macro-substitution19:34
lkclyou can check by doing this19:34
lkcl.set fv0 819:34
lkcl.set fv1 919:34
lkcl.set fv2 1019:34
lkclfmuls fv0, fv1, fv219:35
lkclwelcome to built-in binutils macro pre-processing19:35
ghostmansdI guess it's confused by .v19:41
ghostmansdthat is, it doesn't even understand fv0 is macro when it meets fv0.v19:41
ghostmansdoh wait, I think I know the reason19:42
ghostmansd_we_ don't handle macros19:42
lkclghostmansd, correct... ish19:44
lkclpysvp64asm was *specifically* designed to have support for the ".set" syntax19:44
ghostmansdno I'm talking of binutils19:44
ghostmansdwe kinda have hack as well19:44
lkcloh deep joy19:45
ghostmansdwe parse the operands19:45
ghostmansdbut do not give a crap to macros19:45
lkclahh i thought it was a pre-processing stage19:45
lkclyep sorry i didn't realise.19:45
lkclyes, macro pre-processing has to be done [excluding the .v or .s]19:45
ghostmansdit's OK, actually this is yet another reason to re-consider parsing19:45
ghostmansdbecause this hack we have, our own simple parser, is, well, a hack19:46
ghostmansdit was introduced since operands are sooooo different in SVP64...19:46
ghostmansdI mean, these .s and .v are not part of binutils...19:47
ghostmansdor, well, not part of vanilla PPC should I say19:47
ghostmansdso, they're not in vanilla19:47
ghostmansdso we parse the operands on our own19:47
ghostmansdfor us it's easier since as we discussed we don't have optional operands19:47
ghostmansdso, there are two options19:48
lkcltranslate_one() takes a dictionary of macros19:48
ghostmansdyeah I know19:48
ghostmansdvanilla binutils has these macros19:48
ghostmansdit's simply that we execute our operands remapping before this stage19:49
lkclahh... optional operands maaay be needed in future... separate patch19:49
ghostmansdok, two options19:49
ghostmansd1) refactor the code so that vanilla binutils knows about .s and .v19:49
ghostmansd2) introduce macro substitution to level where we play19:49
ghostmansdactually I _think_ 1) is doable19:50
ghostmansdand, despite some sillyness...19:50
ghostmansdit's more correct, because we'd like to avoid code duplication19:50
ghostmansdand we already duplicate it somewhat with operands parsing19:50
ghostmansdI'll think about it, but this will take some time to implement19:51
ghostmansdanyway, we still wait for GNU assignment19:51
ghostmansdand we need macros anyway19:51
lkclwell, there's EUR 4325 to play with there
ghostmansdyeah will raise it later19:51
ghostmansdhave to check the code now19:51
ghostmansdI recall operands have different flags present19:52
ghostmansdamirite .s and .v do affect only GPR?19:53
lkclyes. they only go into the EXTRA2/3 area19:53
ghostmansdI mean the operand type, sorry19:53
lkclabsolutely nowhere else, and no connection to anything else19:53
lkcloperand type? ehn?19:53
ghostmansd1 sec19:53
lkclyou mean for the v3.0 32-bit suffix?19:54
lkclyes, .s will produce a different 5-bit RA/RB/RC/RT/RS from .v19:54
ghostmansdhere and below19:54
ghostmansdstuff like RA is marked appropriately19:55
ghostmansd#define RA NSISIGNOPT + 119:55
ghostmansd  { 0x1f, 16, NULL, NULL, PPC_OPERAND_GPR },19:55
lkclso you can still have 0.v 0.s19:55
ghostmansd#define FRA FLM + 119:55
lkclr0.v r0.s19:55
ghostmansd  { 0x1f, 16, NULL, NULL, PPC_OPERAND_FPR },19:55
lkclf0.v f0.s19:55
ghostmansdso, GPR, FPR... anything else?19:56
ghostmansdI guess no19:56
lkclCRs BA BB BC19:56
lkcland CR Fields BF and BFA19:56
ghostmansdAha, OK, got it19:56
ghostmansdOK I think I'll teach binutils operand parsing code some new tricks19:56
lkcland probably at some point SPR numbers as well but i don't want to freak you out on that one quite just yet :)19:56
ghostmansdthey tell you can never teach an old dog new tricks... who gives a shit, eh?19:57
lkclbecause yes it's perfectly reasonable to have "sv.mfspr" perform *multiple* SPR mv operations19:57
ghostmansd>  i don't want to freak you out19:57
lkclnothing a good coat of paint won't fix19:57
ghostmansdreminds me of some comment in one task I had at work19:57
ghostmansdwe had "tips, advice and comments" field on bug tracker19:58
ghostmansdsomething like this19:58
ghostmansdand one really shitty task had a nice comment/advice19:58
ghostmansd"never surrender"19:58
ghostmansdmade me laugh for quite a long time19:58
ghostmansduntil I got to closing this task, but that's yet another story :-D19:58
ghostmansdexactly this yeah20:06
Veera[m]<ghostmansd> "sure" <- ghostmansd: Hi22:39
Veera[m]ghostmansd:  Well will work for dev-env-script for binutils-gdb.22:41
Veera[m]ghostmansd: Am I late for this!!!22:41
Veera[m]ghostmansd: Please give instructions here and better in Bug 838.22:41
Veera[m]<lkcl> "ghostmansd, if you can help..." <- lkcl: <btw we do need a "build script" for binutils now>, <Veera: are you happy to do that?>22:47
Veera[m]lkcl: Yes. I will.22:48
lkclVeera[m], we realised actually it is this:;a=blob;f=ppc64-gdb-gcc;hb=HEAD22:56
lkclbut needing modification to use this git repository instead:;a=tree;h=refs/heads/svp64;hb=refs/heads/svp6422:57
lkclat that branch22:57
Veera[m]So, we need a script for binutils and gdb for head svp64.23:00
Veera[m]Host: x86_64 and target powerpc6423:01
Veera[m]or Host: powerpc64 and target: x86_6423:01
lkclVeera[m], yes makes sense23:07
lkclactually, host: powerpc64 and target: powerpc6423:08
lkclthe target is *only* ever powerpc6423:08
lkclbut it needs the names to be the same on both:23:08
lkclactually... powerpc64le :)23:09
lkclhost: powerpc64le   target poewrpc64le-linux-gnu-23:09
lkclhost: x86      target: powerpc64le-linux-gnu-23:09
lkclthe prefix needs to be the same for both23:10
lkclthe situation we *don't* want to end up happening is: host: powerpc6le   target: native (no prefix)23:10
lkclthis will end up replacing /usr/bin/ld and /usr/bin/as on the talos1 workstation!23:11
lkclwhich is absolutely crucial that does not happen!23:11
Veera[m]In which bug no. to start the work?23:15
lkclVeera[m], create a new one, under #57723:16
lkcloctavius, diagrams look damn good23:18
lkcllet's crank the budget up on that one and call it done23:19
Veera[m]lkcl: Mean, Child task under Bug #57723:20
lkclVeera[m], yes23:20
Veera[m]lkcl: one script to cover gcc, binutils and gdb?23:21
lkclbinutis and gdb23:22
lkclnot gcc23:22
lkclactually binutils and gdb are in the same source repository23:22
lkclso just binutils-gdb23:22
Veera[m]lkcl: host: powerpc64le and host: x86_64; 2 scripts or 1 script with some variables to select or automatically depending upon host system?23:25
lkclit should automatically install the exact same target (powerpc64le-linux-gnu-) regardless of the host23:29
lkcland should only use the svp64 branch23:30
lkclover time we will have all upstream patches in. but not yet23:31
Veera[m]I will open a bug report in a short while.23:34
octaviuslkcl, figured may as well do several diagrams in one go, and I realised we can upload the Inkscape .svg directly (meaning it can be updated easily)23:39
octaviuserrors fixed, will send RFP tomorrow23:44
octaviusIs 1500EUR good for bug 762? I could include both in the RFO23:46

Generated by 2.17.1 by Marius Gedminas - find it at!