sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<whitequark> so, you, uh, can't actually build LLVM 3.5 on Ubuntu 12.04
<whitequark> it needs gcc >=4.7
<rjo> there is the backport toolchain.
<rjo> what i used originally iirc.
<whitequark> it has clang 3.4 though
<whitequark> so I'll try using that
<whitequark> oh ffs. no libstdc++
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#332 (master - d65d303 : Robert Jordens): The build has errored.
travis-ci has left #m-labs [#m-labs]
<whitequark> ok, binutils work. great
<GitHub89> [artiq] whitequark pushed 3 new commits to new-py2llvm: http://git.io/vYVaT
<GitHub89> artiq/new-py2llvm 7903889 whitequark: Merge branch 'master' into new-py2llvm
<GitHub89> artiq/new-py2llvm 862ac1f whitequark: lit-test/compiler -> lit-test/test....
<GitHub89> artiq/new-py2llvm 14c7b15 whitequark: Add a test harness for exceptions....
<GitHub119> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYVKS
<GitHub119> artiq/new-py2llvm 47f13bf whitequark: Always load the personality library in JIT testbench, if available.
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#332 (master - d65d303 : Robert Jordens): The build has errored.
travis-ci has left #m-labs [#m-labs]
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#332 (master - d65d303 : Robert Jordens): The build has errored.
travis-ci has left #m-labs [#m-labs]
<GitHub76> [artiq] whitequark pushed 1 new commit to master: http://git.io/vYViL
<GitHub76> artiq/master 905abd6 whitequark: get-toolchain.sh: be less verbose.
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#333 (master - 905abd6 : whitequark): The build has errored.
travis-ci has left #m-labs [#m-labs]
<sb0> WARNING:PhysDesignRules:1362 - Unexpected programming for comp OSERDESE2_107
<sb0> with TRISTATE_WIDTH. DATA_RATE_TQ set DDR expects TRISTATE_WIDTH to be set 4.
<sb0> so, why do they have two parameters?
<sb0> ah, it's not DATA_WIDTH == TRISTATE_WIDTH
fengling has joined #m-labs
fengling has quit [Client Quit]
<whitequark> ImportError: No module named 'mibuild'
<whitequark> wtf
<sb0> so that was from ISE
<sb0> and vivado: ERROR: [Drc 23-20] Rule violation (AVAL-69) OSERDES_DataWidth4Tri1 - Unsupported programming for OSERDESE2_123. DATA_WIDTH set greater than 4 requires TRISTATE_WIDTH to be set to 1
<GitHub196> [artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vYV9U
<GitHub196> artiq/new-py2llvm ef4a06a whitequark: Merge branch 'master' into new-py2llvm
<GitHub196> artiq/new-py2llvm bb5fe60 whitequark: Implement exception raising.
<rjo> 4 == 1 for large ones and small fours.
<whitequark> "and in wartime, pi can approach 4"
<whitequark> yeah
* rjo has finally debugged an extremely annoying issue were my pipistrello would only work in the presence of a human (many weeks of statistics).
<mithro> rjo: what was the issue?
<rjo> the very obvious (after debugging) reason: auto-suspend of the monitor that was powering the thing.
<whitequark> ha!
<whitequark> wait, monitor?
<rjo> monitor with integrated usb hub.
<whitequark> oh. that's evil.
<rjo> yes. a nice monitor with an ir detector that turns off a minute or so after the last warm-blooded animal leaves the room.
<whitequark> hmmm, a crash inside the x86 code generator
<rjo> whitequark: by the way. if you are playing with the pipistrello now, give https://github.com/jordens/openocd a try. also for flashing and loading bitstreams to the fpga. should be much nicer than xc3sprog/fpgaprog and will probably be what you want to use anyway for or1k.
<mithro> hey everyone - Has anyone thought of submitting a talk to Linux.conf.au conference here in Australia? It is kind of a misnamed conference - it should really be OpenSource.conf.au and I'd love to see talks about the m-labs related stuff
* whitequark has considered LCA until they looked at the price
<sb0> hmm, 9:20 flight from HK
<mithro> whitequark: Speakers get free tickets
<whitequark> hrm
<mithro> sb0: yeah - Australia is sucky far away from everywhere :(
<mithro> whitequark: You can even apply for accommodation+travel assistance
<sb0> why does adding another PLL somewhere else in the design break ethernet? wtf.
<sb0> for a moment, it seemed 7-series were better than slowtan6, but no, I had been lucky before and they're the same crap
<mithro> sb0: how much do you think is the devices themselves verses the ISE/Vivado tools?
<whitequark> hm, it explodes *only* inside llvmlite. not via lli. odd.
<whitequark> ssert(ValueVTs.size() == 2 && "Only two-valued landingpads are supported"); well ffs
<whitequark> have they maybe considered supporting output besides that which clang emits, eh??
<sb0> whitequark, you want to go to LCA?
<sb0> mithro, hard to tell
<whitequark> sb0: sure, conf seems interesting and AU is pretty fascinating too
<sb0> The close date for Presentations, Tutorials, Prototypes, and Miniconf proposals is midnight Sunday 2nd August.
<mithro> Just a FYI, I'm on the paper's committee and been attending the conference for 12 years now
<whitequark> er--haven't considered presenting I guess
<whitequark> hmm
<sb0> so, hires-rtio seems to work fine when plugged to the SDRAM PLL, and everything falls apart when adding another PLL for it
<sb0> fuck xilinx, seriously
<sb0> whitequark, and do you want to present? :)
<whitequark> not sure. LCA is pretty large and i never presented in english before
<GitHub29> [artiq] sbourdeauducq pushed 8 new commits to master: http://git.io/vYVNj
<GitHub29> artiq/master d90dff4 Yann Sionneau: rtio: add SERDES TTL (WIP)
<GitHub29> artiq/master 940aa81 Sebastien Bourdeauducq: rtio/ttl_serdes: cleanup/rewrite
<GitHub29> artiq/master f68d5cb Sebastien Bourdeauducq: rtio: forward rtio domain reset to rio and rio_phy domains
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#334 (master - 117b361 : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
<GitHub94> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/vYVAF
<GitHub94> migen/master f32f9be Sebastien Bourdeauducq: resetless -> reset_less
<GitHub99> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vYVAb
<GitHub99> artiq/master 959b7a7 Sebastien Bourdeauducq: rtio: resetless -> reset_less
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#63 (master - f32f9be : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#335 (master - 959b7a7 : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
<sb0> I could handle that, but sitting in the flying sardine can for 19 hours sounds painful ...
<cr1901_modern> whitequark: Do you still need to install llvm on 12.04? I have a shell script which automates the process- it's kinda involved (and/or irritating).
<whitequark> already done
<cr1901_modern> You had to install GCC 4.7+, then cmake (version on 12.04 is too old), then llvm, right?
<whitequark> yes
<cr1901_modern> I gotta ask myself why I thought it was a good idea to write a shell script for something I only had to do once...
fengling has joined #m-labs
cr1901_modern has quit [Read error: No route to host]
cr1901_modern has joined #m-labs
<GitHub131> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYw3W
<GitHub131> artiq/new-py2llvm 7c77dd3 whitequark: Implement __artiq_personality.
<whitequark> lol what the fuck. what were GCC people smoking when they wrote the exception table format
<whitequark> the list of exceptions a catch clause can catch is encoded using a finite state machine with a variable instruction length
<whitequark> instead of, you know, a fucking array. i am guessing that would be too straightforward.
<sb0> received my chinese oscilloscope. in a "fine toiletry" box, of course :)
<whitequark> ha
<whitequark> ok, so the allocas and stack pointer are where they are supposed to be at entry to the handler
<whitequark> => the whole affair was a success
<sb0> shipping cost 7€ by air, took 2 days, and collecting packages takes only a few minutes
<sb0> I wish sf-express would expand to more countries and give UPS and fedex the bankruptcy they deserve
FabM has joined #m-labs
<cr1901_modern> 2-3 business days to the US, according to their website o.0;
<whitequark> that's not hard
<cr1901_modern> Then what causes the delay of 2-3 weeks for my packages from China (Ebay, which is prob my first mistake)?
<whitequark> "free ePacket shipping"
<cr1901_modern> Yep, that would explain it. I get what I pay for in this case.
<GitHub61> [artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vYwRV
<GitHub61> artiq/new-py2llvm 90be44c whitequark: Add tests for non-exceptional control flow across finally.
<GitHub61> artiq/new-py2llvm a83e7e2 whitequark: Add tests for exceptional control flow.
<whitequark> sb0: ping
<whitequark> a semantics question
<whitequark> I can have the finally: clauses behave with regard to exceptions a little more like in Python (they're just catch-all clauses that implicitly re-raise), or a little more like in C++ (they are dedicated to cleanup code)
<whitequark> the difference is
<whitequark> in #1, if no except clause will catch the exception, you'll still get unwinding
<whitequark> in #2, if no except clause will catch the exception, the runtime will immediately terminate
<whitequark> since we have no heap on which to store the backtrace, in case #1 the backtrace will get fucked
<whitequark> but in case #2 the backtrace will accurately resemble the callstack
<whitequark> of course, in case #1 you have a chance to do something funky like returning out of finally clause, or raising another exception there
<sb0> well, unwinding is only useful when the exception is not caught, isn't it?
<whitequark> huh?
<whitequark> no, unwinding always happens. in fact, twice. the first time, the unwinder asks every stack frame whether it can handle the exception in-flight
<sb0> maybe not with DWARF and other fancy mechanisms :) but at compared to the current sjlj system, the point of adding unwinding was to get debug info on uncaught exceptions
<whitequark> and the second time it peels off stack frames one-by-one (well, several if they don't have any try statements) and tells them to clean after themselves or handle
<whitequark> ok, so do I understand you prefer #2?
<whitequark> immediate termination / no finally clause execution / accurate traces?
<sb0> no, the finally clauses should get executed like Python does
<sb0> what about sending the elements of the backtrace over the network one by one? we don't care about speed
<whitequark> hrm
<whitequark> so what happens if a second exception is thrown while unwinding?
sb0 has left #m-labs ["Leaving"]
sb0 has joined #m-labs
<sb0> what would throw such an exception?
<sb0> oh, I see, since you are not using sjlj you need to unwind every time an exception is thrown
<sb0> and you need to keep info on the previous frames in case nothing ends up catching the exception, and you need to send that info to the comms CPU/PC?
<whitequark> yeah
<whitequark> well, not quite.
<whitequark> I can say whether something will *catch* the exception right when it is raised (phase 1)
<whitequark> but I cannot say whether the finally clauses, which execute /as a part of unwinding/, will raise another exception or just return
<whitequark> they execute as a part of unwinding, during phase 2, because they need access to local variables and such
<whitequark> there is a different but related issue with rethrowing exceptions
<sb0> what about rescanning the stack frames when you need to send the trace to the host?
<whitequark> since "except x: ... raise" is equivalent to a finally clause that's selective and gives access to the exception
<whitequark> ha.
<sb0> you'd only get the last exception thrown, but that should be OK
<whitequark> that was my original plan.
<sb0> and what is wrong with it?
<whitequark> if I execute finally clauses even when the exception will not be caught, by the time I need to send the backtrace to host, I don't *have* the stack frames
<whitequark> since they've been popped off
<sb0> ah, I see.
<sb0> what about a static backtrace buffer of a few kilobytes?
<whitequark> so it is either 1) not executing finally clauses for uncaught exceptions or 2) storing them somewhere
<sb0> or dozen kilobytes
<whitequark> that can be done.
<whitequark> well, you don't need kilobytes, really, it's 4 bytes per entry
<sb0> there's 1GB RAM on those boards, so it should not be an issue at all.
<whitequark> ok. so if it's uncaught, I will force unwinding while collecting the PCs
<whitequark> and if a finally clause bails, I'll just never get control from the unwinder back
tija has joined #m-labs
<sb0> "The MMCM outputs are programmed to provide (for example) a 528 MHz processor clock"
<sb0> xilinx datasheet are always so optimistic.
<whitequark> ha
<sb0> right now, if the design worked at all at 125MHz when using more than one of those MMCMs, that would be nice
<GitHub72> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYr3V
<GitHub72> artiq/new-py2llvm 2939d4f whitequark: Add tests for finally clause and reraising.
nicksydney_ has joined #m-labs
nicksydney has quit [Ping timeout: 272 seconds]
_whitelogger___ has joined #m-labs
fengling_ has joined #m-labs
_whitelogger__ has quit [Ping timeout: 240 seconds]
fengling has quit [Read error: Connection reset by peer]
<sb0> "Signal controls the state of the input MUX, High = CLKIN1, Low = CLKIN2"
<sb0> default 0, e.g. CLKIN2, whereas the base PLL defaults to CLKIN1
<sb0> grrrr
<sb0> FINALLY got that damn think to lock and produce a valid clock without screwing other parts of the design
<sb0> *thing
<sb0> now, locking the output phase to the input. surely, that will fail again.
<whitequark> wow, I did the backtrace thing
<whitequark> it works /too well/
<sb0> whitequark, cool :)
<sb0> what does it do?
fengling_ has quit [Ping timeout: 252 seconds]
<whitequark> I mean, it's expected, really, though it's still neat
<sb0> nice
<whitequark> so... to get line numbers, we'll need a full-blown DWARF parser
<whitequark> I think I'll just use libdwarf on the host
<whitequark> and build everything with debug info
<whitequark> well, not everything, just the python parts
<whitequark> unless you want C backtraces too, which I can also do
<sb0> no, C backtraces are not necessary
<whitequark> the artiq exception/backtrace machinery, as currently designed, is not specific in operation to ARTIQ at all
<GitHub30> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYrQa
<GitHub30> artiq/new-py2llvm edffb40 whitequark: On uncaught exception, execute finally clauses and collect backtrace.
<whitequark> well, except the exception format
<whitequark> for example, this ↓
<GitHub101> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYr5W
<GitHub101> artiq/new-py2llvm 244ace1 whitequark: Add artiq_raise_from_c macro.
<sb0> rjo, do you know what the synthnv baud rate is? and can I connect its input to a LVCMOS 25 FPGA pin (according to Joe yes, but I have learned to double-check this sort of thing...)
<whitequark> ok, let's write the dynamic linker
<whitequark> hm
<whitequark> ha, ksupport doesn't fit into 4K anymore
<whitequark> hm, how do I flash runtime without xc3sprog?
<whitequark> haha, I can't even get xc3sprog. sourceforge is dead
<whitequark> got it. sure enough, it doesn't work
_whitelogger___ has joined #m-labs
<sb0> ok, I can talk to the synthnv and get the right signal on the scope. now, the ref input...
<sb0> whitequark, yes, flashing the runtime with xc3sprog will fail
<sb0> whitequark, load from serial. flterm --port /dev/ttyUSBx --kernel runtime.bin
<sb0> or figure out openocd :)
nicksydney has joined #m-labs
nicksydney_ has quit [Ping timeout: 244 seconds]
<whitequark> hrm
<whitequark> hrm, runtime miscompiles. I wonder why
<whitequark> ohhh, this is a different miscompilation than before. exciting
antgreen has quit [Remote host closed the connection]
attie has quit [Remote host closed the connection]
<whitequark> ha, neat. what makes the bug manifest is uncommenting a 4th strcmp in do_command in test_main.c
<sb0> this is why I waited before pulling your misoc commit :-)
<whitequark> my guess would be an extremely poor choice by the register allocator coupled with the spiller doing something it shouldn't
<whitequark> the assembly shows that do_command got inlined into test_main and test_main spends several screens stashing... something... into stack slots
nengel has joined #m-labs
<sb0> yay, phase locking
<GitHub146> [artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/vYo8z
<GitHub146> artiq/master b1d58bd Sebastien Bourdeauducq: rtio: fix replace/sequence_error when fine_ts_width > 0
<GitHub146> artiq/master d7138b2 Sebastien Bourdeauducq: examples/ddb: add device aliases for unittests
<GitHub146> artiq/master fe57308 Sebastien Bourdeauducq: runtime: support for RTIO PLL
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#336 (master - 2a95e86 : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
tija has quit [Quit: Connection closed for inactivity]
sb0_ has joined #m-labs
sb0 has quit [Read error: Connection reset by peer]
sb0_ has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<sb0> my computer seems to love USB ground loops
<whitequark> hrm, i've reduced it to a 130-line assembly file
<whitequark> still not sure why exactly it happens, though
<whitequark> lol, what.
<whitequark> i mean WHAT.
<whitequark> it ate byte stores.
<whitequark> just decided not to emit them.
<whitequark> oh my god
<whitequark> the reason it worked in some cases is because the registers accidentally matched. i think
<whitequark> ah, no. no. it emits byte stores if i remove the large alloca
<whitequark> sb0: good thing i found this *now*, and not when artiq started uploading python kernels with shittons of allocas
<whitequark> it can't encode l.sb -32768(r2), r3, so it decides to not emit it at all
<whitequark> probably a bug in DAG legalize or instruction selection
ylamarre has joined #m-labs
<whitequark> hm, neither. it's in frame index eliminator
<whitequark> i strongly suspect this could have never possibly worked
_florent_ has joined #m-labs
fengling_ has joined #m-labs
fengling_ has quit [Ping timeout: 252 seconds]
<whitequark> sb0: should flash storage just work after fserase, or do I need some kind of initialization?
<sb0> should work after fserase
<whitequark> says it is full
<sb0> what are you writing to it?
<whitequark> "fswrite key value"
<sb0> what key/value? and it works here... both pipistrello and kc705.
<whitequark> just "fswrite key value"
<whitequark> literally that
<sb0> let me test again
<whitequark> can you upload your runtime.fbi so I don't have to rebuild everything?
<whitequark> well, .bin
<sb0> test> fserase
<sb0> test> fswrite key value
<sb0> test>
<sb0> I'm building for kc705
<whitequark> ah
<sb0> and you don't have to rebuild everything, just build-headers in misoc + make in runtime
early` has quit [K-Lined]
<whitequark> do I understand it correctly that flash is just memory-mapped?
<sb0> yes
<sb0> for reads
<whitequark> and for writes?
<sb0> bitbang SPI
early has joined #m-labs
<sb0> olofk, ^
<whitequark> so, i did mr in bios, and it's just ff ff
<sb0> at what address?
<whitequark> 0x001c0000
<whitequark> which ... seems to be right, after flash_erase?
<sb0> yes
[florian] has quit [Ping timeout: 244 seconds]
[florian] has joined #m-labs
<whitequark> hm. it works now. i'm not sure why it didn't work before
<whitequark> passes fstest too
fengling_ has joined #m-labs
<sb0> whitequark, should llvm work now? can I pull your misoc commits?
<whitequark> yes
<whitequark> I wonder if building it with -O3 works
fengling_ has quit [Ping timeout: 246 seconds]
<whitequark> yup
<GitHub16> [artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/vY6Z5
<GitHub16> artiq/master 256e99f Sebastien Bourdeauducq: kc705: crg cleanup
<GitHub16> artiq/master 299bc1c Sebastien Bourdeauducq: kc705: output divided-by-2 RTIO clock
<GitHub16> artiq/master 09d837e Sebastien Bourdeauducq: runtime: monitor RTIO clock status
<GitHub109> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/vY6Zx
<GitHub109> migen/master b7784fc Sebastien Bourdeauducq: platforms/kc705: add GPIO SMA
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#337 (master - 7feaca7 : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#64 (master - b7784fc : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
<GitHub189> [artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/vY603
<GitHub189> artiq/master 228f7c3 Sebastien Bourdeauducq: manual: update xc3sprog download
<GitHub189> artiq/master 0cd7453 Sebastien Bourdeauducq: runtime: more explicit message about startup clock failure
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#338 (master - 0cd7453 : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
<whitequark> err
<whitequark> that's a mismatch between llvmlite and LLVM, but
<sb0> it's your llvm and your llvmlite
<sb0> or, wait, maybe it's using the system llvm includes
<whitequark> oh, yeah, right
<sb0> let me delete them
<whitequark> no
<whitequark> *I* was using system LLVM includes
<whitequark> one moment, I will fix.
<whitequark> yep, it emits a ton of errors
<sb0> yes. that was just the first
<whitequark> are you trying to build new-py2llvm or master?
<sb0> master
<sb0> clang is also problematic. http://paste.debian.net/286609/
<whitequark> hm, I don't think I updated llvmlite
<whitequark> that one is simple. you need or1k-linux-* binutils
<sb0> that's built with the instructions from the current artiq doc
<sb0> yes, I did that
<whitequark> are they in PATH?
<sb0> yes
<whitequark> can you `make crt0-or1k.o V=1` and add -### as the first clang parameter?
<whitequark> it will show what the driver is executing
<sb0> meh, /bin/as
<whitequark> yes. the way it works is that it searches for $(TRIPLE)-as in $PATH
<whitequark> if it can't find that in $PATH, it fallbacks to as
<sb0> I do have or1k-linux-as in PATH
<sb0> or does it look for or1k--linux-as for some reason?
<sb0> nope...
<whitequark> no, it doesn't
<rjo> sb0: i have to check on the baud rate.
<sb0> rjo, 115200 works
<sb0> rjo, and it can take the lvcmos levels
_florent_ has quit [Ping timeout: 250 seconds]
<sb0> rjo, now the problem is it wants a 10MHz clock, which is a pain to generate from the K7, and making it accept another frequency is also a pain
<whitequark> try `strace -ff -estat clang ...`
<whitequark> although, no, that won't show anything if it can't find the linker
<whitequark> let me look at clang source
<rjo> sb0: the output is 50 Ohm sine (obviously unbal). -60 dBm to 19 dBm. i have no idea which 50 ohm power is "appropriate" for lvcmos25.
<sb0> rjo, I'm talking about its clock input, to phase-lock it to the FPGA
<rjo> ah.
<sb0> rjo, the idea was to feed the internal 125MHz FPGA clock to it
<sb0> there are two problems with it
<sb0> 1) max freq is 100MHz, but that's easy, I can use 62.5
<sb0> 2) PLHell configuration
<sb0> because it wants 10MHz
<rjo> what is that setup for?
<sb0> send 1GHz to the AD9914s
<rjo> why do you want to lock it to the gpga?
<rjo> fpga
<sb0> to test phase control
<rjo> hmm. you only have one dds?
<sb0> yes
<rjo> you could throw the 125 Mhz from the dds syncclk into the fpga and edge-time that with the new serdes-gpio.
ylamarre has quit [Quit: ylamarre]
<sb0> at least, clang seems to know a few things about or1k, as it does generate assembly code for it when compiling C
<sb0> but it still tries to pass that to as
<whitequark> ha, so, you can't override tool names in clang. at all.
<whitequark> a simple workaround is to do export PATH=/usr/local/or1k-linux/bin:$PATH
<sb0> nope
<whitequark> nope what?
<sb0> it still runs the wrong as ...
<whitequark> wtf
<sb0> $ which as
<sb0> /usr/local/or1k-linux/bin/as
<whitequark> that makes no sense
<whitequark> did you build clang from scratch?
<sb0> clang runs "/..//bin/as"
<sb0> yes
<whitequark> hm
<whitequark> what's in your PATH?
<whitequark> might it be that there is something like /..: ?
<sb0> no, there isn't
<whitequark> ok, let's try another way
<sb0> well, the install instructions need to work.
<whitequark> sure
<whitequark> I don't understand what is necessary to reproduce your problem, though. I never encountered anything like that
<whitequark> so, if you can use my prebuilt llvm-or1k, it means the problem is in the build. otherwise, in the environment
<sb0> same problem with yours
<whitequark> ok, so it is not the clang build, because I just verified that and it works here
<whitequark> hm
<whitequark> can you execute the as?
<sb0> even after
<sb0> export PATH=/usr/local/bin:/usr/local/llvm-or1k/bin:/usr/bin:/bin
<sb0> it still fails
<sb0> how do I make it keep the tempfiles?
<whitequark> specifically tempfiles? I don't know. you can pass -### and execute what it says
<sb0> yes, running or1k-linux-as manually works
<sb0> both for C and S
<sb0> and also when doing that with the clang I built myself
<whitequark> ok, I figured out why that happens
<whitequark> it has some extremely bizarre distro (not even OS!) detection code
<whitequark> and which search path you will get depends on whether you have multilib gcc
<sb0> yeah, things like that and the store bug is why I kept building with gcc :)
<sb0> though yes, the store bugs could have manifested itself in artiq as well
<whitequark> clang's driver is easily the worst part of it, yes
<whitequark> what system do you have, so that i could reproduce it locally?
<sb0> arch linux
<whitequark> sigh
<whitequark> ok, I need to sleep. I'll figure something out tomorrow
<sb0> hm. have you tried building the bios?
<sb0> LD bios.elf
<sb0> or1k-linux-ld: bios.elf section `.rodata' will not fit in region `rom'
<sb0> Makefile:19: recipe for target 'bios.elf' failed
<sb0> or1k-linux-ld: region `rom' overflowed by 1492 bytes
<whitequark> sure, I've built bios and artiq and ran them both
<sb0> (I have replaced /bin/as with the or1k as for now)
<sb0> oh, but for pipistrello, right?
<whitequark> yes
<sb0> which doesn't have netboot
<sb0> ok, that explains it
<whitequark> yes
<sb0> similarly
<sb0> or1k-linux-ld: ksupport.elf section `.text' will not fit in region `ksupport'
<sb0> or1k-linux-ld: region `ksupport' overflowed by 5256 bytes
<sb0> Makefile:33: recipe for target 'ksupport.elf' failed
<whitequark> yes. that's even on pipistrello
<sb0> and that's with master, not new-py2llvm
<whitequark> expected from -fPIC
<whitequark> yes, I forgot to push
<sb0> 5256 additional bytes is a lot of code. more than 2x what it was
<whitequark> didn't you tell me just a few hours ago that memory is not at all a problem?
<GitHub15> [artiq] whitequark pushed 1 new commit to master: http://git.io/vYiTN
<GitHub15> artiq/master eec4a2d whitequark: Update buildsystem to track -fPIC and ranlib removal in MiSoC.
<sb0> well, within limits. 2x more code also means more cache misses and slower execution
<whitequark> -fomit-frame-pointer should get it back within limits
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#339 (master - eec4a2d : whitequark): The build has errored.
travis-ci has left #m-labs [#m-labs]
<sb0> you forgot to update kloader.h
<sb0> and even after I did, the runtime just crashes at boot
<sb0> Executing booted program.
<sb0> ARTIQ runtime bui
<GitHub82> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vYiIH
<GitHub82> artiq/master ae3a52c Sebastien Bourdeauducq: runtime: fix KERNELCPU_PAYLOAD_ADDRESS
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#340 (master - ae3a52c : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
<whitequark> sb0: ok, can you try without -fPIC?
<sb0> good thing I sorted out the hires-rtio before pulling :) I was totally expecting such a constant stream of bugs
fengling_ has joined #m-labs
<sb0> same thing without -fPIC.
<whitequark> hmm
<sb0> going to bed as well. gn8
<whitequark> ok, night
fengling_ has quit [Ping timeout: 246 seconds]
fengling_ has joined #m-labs
fengling_ has quit [Ping timeout: 246 seconds]
<rjo> sb0, fallen: anyone working on pipistrello hires rtio? if no, i'll give it a shot.
fengling_ has joined #m-labs
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined #m-labs
fengling_ has quit [Ping timeout: 246 seconds]
dddd has joined #m-labs
dddd has quit [Client Quit]