scrts has quit [Ping timeout: 240 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
scrts has joined ##openfpga
amclain has quit [Quit: Leaving]
digshadow has quit [Ping timeout: 260 seconds]
scrts has quit [Ping timeout: 245 seconds]
scrts has joined ##openfpga
Zarutian has quit [Quit: Zarutian]
oeuf has quit [Read error: Connection reset by peer]
oeuf has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
Bike has joined ##openfpga
azonenberg_work has quit [Ping timeout: 260 seconds]
azonenberg_work has joined ##openfpga
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 255 seconds]
scrts has quit [Ping timeout: 260 seconds]
flaviusb has quit [Quit: Leaving.]
Bike has quit [Quit: leaving]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
wpwrak has quit [Ping timeout: 240 seconds]
wpwrak has joined ##openfpga
scrts has joined ##openfpga
Hootch has joined ##openfpga
UmbralRaptor has quit [Quit: *BAMF!*]
pie_ has joined ##openfpga
m_w has quit [Quit: leaving]
digshadow has joined ##openfpga
talsit has left ##openfpga [##openfpga]
m_t has joined ##openfpga
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
_whitelogger has joined ##openfpga
whitequark has joined ##openfpga
pie_ has quit [Changing host]
pie_ has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<rqou> whitequark: i'm currently playing around with dropping gcc for clang
<rqou> for my particular test case it seems that replacing arm-none-eabi-gcc with "clang --target=arm-none-eabi -isystem <cross gcc includes dir>" works
<rqou> at least for compiling individual source files
<rqou> but i can't get clang to do the final link step
<rqou> i currently use "arm-none-eabi-gcc -v $CFLAGS -B.. -specs=../linkspecs.specs -o poke-tool.elf -Wl,-Map=poke-tool.map *.o"
<rqou> which seems to do some multilib magic
<rqou> how do i make clang do the same thing?
<whitequark> you can't. clang has no way to parse gcc's -specs files, thankfully
<whitequark> multilib options are basically hardcoded per triple
<rqou> ok, the contents of the specs file are the following:
<rqou> %rename link old_link
<rqou> *link:
<rqou> %(old_link) ldscript.ld%T --gc-sections
<rqou> *startfile:
<rqou> crti%s crtbegin%s
<rqou> is there a way to make clang perform an equivalent thing?
<whitequark> just pass the equivalent -Wl, options?
<whitequark> put crtio.o crtbegin.o -Wl,ldscript.ld -Wl,--gc-sections before $CFLAGS
<whitequark> should suffice
<whitequark> erm
<whitequark> -Wl,-T,ldscript.ld
<rqou> what about some stuff in the documentation about constructor functions?
<rqou> "The program collect2 works by linking the program once and looking through the linker output file for symbols with particular names indicating they are constructor functions. If it finds any, it creates a new temporary ‘.c’ file containing a table of them, compiles it, and links the program a second time including that file. "
<whitequark> no idea whatsoever
<whitequark> wow, that is a horrible hack
<whitequark> well...
<whitequark> that explains one reason why clang shells out to gcc for linking
<rqou> is this _required_?
<whitequark> hm?
<whitequark> collect2?
<whitequark> hang on
<whitequark> is that just assembling .init/.fini sections?
<rqou> maybe?
<whitequark> if that's just .init/.fini then you don't need collect2 or any such hacks, the linker script alone works
scrts has quit [Ping timeout: 240 seconds]
<whitequark> and I'm vaguely certain that clang will emit constructors into .init
<whitequark> so try ignoring the existence of collect2 and see
<rqou> it seems to work, how do i make sure it works "for real?"
<rqou> "The last variant uses neither arbitrary sections nor the GNU linker. This is preferable when you want to do dynamic linking and when using file formats which the GNU linker does not support, such as ‘ECOFF’. In this case, TARGET_HAVE_CTORS_DTORS is false, initialization and termination functions are recognized simply by their names. This requires an extra program in the linkage step,...
<rqou> ...called...
<rqou> ...collect2. "
<rqou> does this imply that for ELF i never need collect2?
<whitequark> one would think so
scrts has joined ##openfpga
<rqou> whitequark: do you know how gcc obtains paths such as "<snip>/bin/../lib/gcc/arm-none-eabi/6.3.0/../../../../arm-none-eabi/lib/thumb/cortex-m0"?
<rqou> is this part of the multilib magic?
<whitequark> it's a part of the specs file I think
<whitequark> again, provide the -L flags yourself
<rqou> the built-in one right?
<whitequark> yes
<rqou> ah ok
<whitequark> it's fairly generic
<rqou> yes, providing the -L flags manually appears to work
<rqou> anyways, tl;dr i've actually managed to replace arm-none-eabi-gcc with system clang and it works!
<whitequark> *nod*
<rqou> unfortunately i still need the gcc build system to get libraries built
<rqou> in all the right permutations
<rqou> i'm not sure how to even begin attacking this problem
<rqou> gcc magically can build newlib by symlinking some stuff around
<rqou> and it builds it for all the multilib permutations
<rqou> same with libstdc++
<rqou> how do i begin replacing this with a "doesn't need gcc?"
<whitequark> what's the problem exactly?
<whitequark> just give it the cflags and ldflags
<whitequark> also, libstdc++? libc++
<rqou> original problem: i'm trying to remove all traces of gcc
<whitequark> I'm not sure if libstdc++ can exist separately from gcc
<rqou> my current gcc is a giant clusterf*ck that also knows how to build newlib
<rqou> i don't know how to untangle this
<whitequark> newlib isn't a component of gcc
<rqou> currently i do "ln -s ../newlib-2.5.0.20170323/newlib/ ." into the gcc directory
<rqou> (this was a copypasta from somewhere)
<rqou> and then gcc magically builds it
<whitequark> have you tried reading the newlib README
<rqou> gcc even has a "--with-newlib" option that does something???
<rqou> right, running ./configure by itself didn't work when glued with gcc
<rqou> gcc and newlib are somehow circularly dependent
<rqou> or maybe they aren't and i'm just dumb
<whitequark> that's an artifact of gcc's stupid build process
<rqou> quite possibly
<rqou> i'm trying to understand how to untangle it
<whitequark> it's not tangled
<whitequark> just use newlib's configure
<rqou> so currently i build gcc like this: `CFLAGS_FOR_TARGET="-O2" CXXFLAGS_FOR_TARGET="-O2" ../gcc-6.3.0/configure --target=arm-none-eabi --prefix=/opt/rqou-fix-arm-stuff-again --enable-multilib --enable-languages="c,c++" --with-newlib --with-gnu-as --with-gnu-ld --disable-nls --enable-threads --with-headers=newlib/libc/include --disable-libssp --disable-libstdcxx-pch --disable-libmudflap...
<rqou> ...--disable-libgomp --disable-werror --enable-cxx-flags='-ffunction-sections' --disable-libstdcxx-verbose --enable-poison-system-directories --enable-interwork --disable-dependency-tracking --disable-win32-registry --enable-lto --disable-newlib-supplied-syscalls --enable-newlib-mb`
<rqou> so clang doesn't need a c runtime to do stuff?
<rqou> OH WAIT
<rqou> i think the dependency was due to libstdc++
<whitequark> what
<rqou> which needs a c runtime
<whitequark> sure
<rqou> but for clang, what happens with libc++?
<rqou> it isn't part of the clang build, is it?
<whitequark> build newlib, then build libc++?
<whitequark> you can build it as a part of clang, just like libcompiler_rt
<rqou> so i need to tell the clang build process to first build the "libgcc-equivalent"
<whitequark> no
<rqou> then build newlib
<rqou> no?
<whitequark> no.
<whitequark> libcompiler-rt is the equivalent of libgcc
<rqou> does newlib not need libcompiler-rt?
<whitequark> so... build libcompiler-rt then newlib then libc++
<whitequark> newlib doesn't
<whitequark> clang's output does
<rqou> aah ok
<rqou> but libc++ does need newlib or an equivalent c runtime, right?
<rqou> i just need to build newlib first
<whitequark> well how else would it work?
<whitequark> it has to implement stuff like cout
<rqou> gcc's build system does it by complete magic
<whitequark> there's nothing magical about it, it's not a circular dependency...
<whitequark> oh and you'll also need libunwind for exceptions
<rqou> by magic i'm referring to the gcc toplevel make knowing how to descend into libstdc++ and build the multilib permuations
<rqou> it all happens as part of one massive make command
<whitequark> that one uses c++ *but* does not have a dependency on libc++
<rqou> i'm not currently trying to untangle circular dependencies
<rqou> i'm just trying to understand the gcc make clusterf*ck
<rqou> and how clang does it better
<whitequark> I think it has a basic topological sort somewhere inside
<rqou> so i need to inform it about newlib?
<rqou> or just manually tell it "don't do libc++ yet"
<whitequark> and some logic to pass arguments around (which may or may not be just --disable-option-checking
<whitequark> incidentally I just realized why that one exists, and it is disturbing
<whitequark> inform what about newlib?
<rqou> i believe gcc's make also has various subtargets that aren't documented very well
<rqou> ok, let's start over
<rqou> what i have:
<whitequark> build libcompiler-rt -> newlib -> libunwind -> libc++abi -> libc++
<whitequark> this order should just work
<rqou> 1) symlink newlib into the gcc tree
<rqou> 2) gcc's build system somehow realized i did this symlink
<rqou> 3) gcc's build system does a topological sort and builds
<rqou> what i want:
<rqou> 1) no symlink required
<rqou> 2) just tell clang manually to build compiler-rt
<rqou> 3) manually build newlib
<rqou> 4) manually build c++ bits
<rqou> can i do this?
<whitequark> why do you insist on clang building compiler-rt
<whitequark> are you not content with the compiler buildsystem building a compiler?
<rqou> er, what else would you use?
<rqou> ok, fine
<rqou> what i want:
<whitequark> this is not an idle question
<whitequark> let's say you have a fp and nofp targets
<whitequark> these have different compiler-rts
<rqou> 1) no symlink hack required
<rqou> er, ok
<rqou> so clang's build system knows how to do the multilib permutations for compiler-rt
<whitequark> like, you build sysroot completely separate from the compiler
<rqou> ?
<whitequark> no
<whitequark> not in general, I don't think it does
<rqou> so what part of the process actually builds compiler-rt?
<whitequark> you.
<rqou> i have to manually build compiler-rt for each multilib version?
<whitequark> sure
<rqou> ok
<whitequark> clang doesn't have multilib for none targets anyway
<whitequark> there's no "multilib" in this configuration, just several sysroots
<rqou> so the topological sort you mentioned
<whitequark> with separate triples or arch options or w/e
<rqou> are you the user doing it?
<whitequark> sure
<rqou> ah ok
<rqou> i was misunderstanding and thought there was some existing mechanism that did it
<rqou> gcc seems to have that
<whitequark> you can build libcompiler-rt and libc++ as a part of clang
<rqou> but you don't have to?
<whitequark> but I do not believe it has a lot of insight into doing it
<whitequark> and in general this works if you're building one compiler for one target for the same system that you're running or something like that
<whitequark> the typical desktop use case, right
<rqou> so for my use case i likely don't even want this?
<whitequark> if you're cross-compiling just build everything yourself, it'll pay off
<whitequark> correct
<rqou> ok that's what i wanted in the first place
<rqou> for gcc you have to fight it
<rqou> so for clang i can "just do it?"
<whitequark> yeah
<rqou> so can i just do the following?
<rqou> 1) install clang from distro
<rqou> 2) for each multilib variant:
<rqou> 3) build compiler-rt
<rqou> 4) build newlib
<rqou> 5) build c++ bits
<rqou> er, 0) build binutils because we still need that
<rqou> this should work, right?
<rqou> everything is explicit and manual and clearly separated
<whitequark> yes, you can
<whitequark> you can also get binutils from distro, or you could get lld there
<rqou> for many of my use cases i can't use lld
<rqou> or can i?
<whitequark> hm?
<rqou> i currently use a linkscript to assign sections to memory addresses
<rqou> for a uC
<rqou> can lld actually do this?
<whitequark> let me see
<whitequark> it looks like you can now
<rqou> oh?
<whitequark> they implemented memory regions
<rqou> recently?
<rqou> hrm, my debian install doesn't even have lld
<rqou> eh i don't mind having to use binutils for now
<rqou> binutils is reasonably self-contained
<rqou> i actually have a .s that chokes llvm too
<rqou> :P
<whitequark> well give it to me
<rqou> nah i can probably fix it if i actually bothered
<whitequark> then fix it
<rqou> tomorrow; sleep time
<rqou> thanks for helping me understand how to move forward
<whitequark> this is a clusterfuck
<rqou> anyways, i can't really test anything until my devboard comes in
<rqou> i've misplaced most of mine
<whitequark> why... why does the linux kernel have .eh_frame in it
scrts has quit [Ping timeout: 260 seconds]
<rqou> does clang have a much saner initializer mechanism than crti/crtn/crtbegin/crtend ?
<whitequark> that's not for clang to choose
<whitequark> but for the libc
<rqou> er, really?
<rqou> newlib doesn't have any of those
<rqou> they seem to belong to libgcc
<whitequark> hm
<rqou> newlib only has crt0
<whitequark> oh god
<rqou> yeah: ./libgcc/config/arm/crti.S
<whitequark> ok well so what clang does is assembles a table of function pointers in a section
<whitequark> so what LLVM does is something like
<whitequark> @llvm.global_ctors = appending global [1 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 65535, void ()* @_GLOBAL__sub_I_x.cpp, i8* null }]
<whitequark> in the IR
<whitequark> that translates into .init_array
<rqou> right, so newlib has a __libc_init_array that iterates over .init_array
<whitequark> yeah you're all set
<rqou> you need to manually call __libc_init_array from crt0
<rqou> but you always had to do that anyways
<rqou> what about .init/.fini?
<whitequark> I don't know what nutjob thought of crti
<whitequark> clang doesn't emit anything into .init
<rqou> does clang not need it?
<whitequark> I don't think you even *can* emit anything into .init with clang
<whitequark> (in the format that the ABI expects)
<rqou> actually
<rqou> newlib's __libc_init_array calls _init
<rqou> which is in crti
<rqou> so *that's* how this shit fits together
<rqou> so clang just doesn't emit this at all?
<whitequark> nah
<whitequark> it emits only .init_array
<whitequark> actually, I think on some targets it will emit .ctors
<whitequark> which I suppose is subtly different
<rqou> eh whatever :P
<rqou> so i can probably just shut newlib up by defining "void _init() {}" somewhere?
<whitequark> I think so
<rqou> alright, nice
<rqou> going to poke this more later
<rqou> thanks
flaviusb has joined ##openfpga
massi has joined ##openfpga
m_t has quit [Quit: Leaving]
<whitequark> rqou: incidentally
<whitequark> I strongly recommend you to squish all parts of your configuration into the ldscript
<whitequark> you can put crt*.o stuff there, you can put library search paths there
<whitequark> then you just need to provide one -L and one -T option for your consumers to put into LDFLAGS
<whitequark> that makes it easier to update toolchain if something hardcodes that into configuration or w/e
talsit has joined ##openfpga
flaviusb has quit [Quit: Leaving.]
Bike has joined ##openfpga
scrts has joined ##openfpga
flaviusb has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
firebalrog has joined ##openfpga
fpgacraft2_ has joined ##openfpga
fpgacraft1_ has joined ##openfpga
firebalrog has quit [Quit: firebalrog]
cblam_ has joined ##openfpga
rqou_ has joined ##openfpga
rah_ has joined ##openfpga
promach has joined ##openfpga
promach has quit [Remote host closed the connection]
ants` has joined ##openfpga
SpaceCoaster_ has joined ##openfpga
promach has joined ##openfpga
ZipCPU_ has joined ##openfpga
indy_ has joined ##openfpga
indy has quit [*.net *.split]
ZipCPU has quit [*.net *.split]
promach_ has quit [*.net *.split]
fpgacraft1 has quit [*.net *.split]
cblam has quit [*.net *.split]
rah has quit [*.net *.split]
fpgacraft2 has quit [*.net *.split]
azonenberg has quit [*.net *.split]
kristianpaul has quit [*.net *.split]
SpaceCoaster has quit [*.net *.split]
nats` has quit [*.net *.split]
_florent_ has quit [*.net *.split]
rqou has quit [*.net *.split]
fpgacraft2_ is now known as fpgacraft2
rqou_ is now known as rqou
ants` is now known as nats`
fpgacraft1_ is now known as fpgacraft1
cblam_ is now known as cblam
firebalrog has joined ##openfpga
azonenberg has joined ##openfpga
promach has quit [Client Quit]
_florent_ has joined ##openfpga
promach has joined ##openfpga
ZipCPU_ is now known as ZipCPU
firebalrog has quit [Remote host closed the connection]
amclain has joined ##openfpga
eduardo__ has quit [Quit: Ex-Chat]
Zarutian has joined ##openfpga
Finnpixel has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
digshadow has quit [Quit: Leaving.]
fpgacraft1_ has joined ##openfpga
uovo has joined ##openfpga
cblam has quit [Ping timeout: 252 seconds]
forrestv has quit [Ping timeout: 252 seconds]
oeuf has quit [Ping timeout: 252 seconds]
fpgacraft1 has quit [Ping timeout: 252 seconds]
fpgacraft1_ is now known as fpgacraft1
cblam has joined ##openfpga
forrestv has joined ##openfpga
Zarutian has quit [Quit: Zarutian]
digshadow has joined ##openfpga
massi has quit [Quit: Leaving]
Zarutian has joined ##openfpga
m_t has joined ##openfpga
Zarutian has quit [Ping timeout: 260 seconds]
Zarutian has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
hobbes- has quit [Ping timeout: 264 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
hobbes- has joined ##openfpga
hobbes- has quit [Read error: Connection reset by peer]
hobbes- has joined ##openfpga
Marex has quit [Ping timeout: 255 seconds]
Marex has joined ##openfpga
Hootch has quit [Read error: Connection reset by peer]
zino has quit [Remote host closed the connection]
m_t has quit [Quit: Leaving]
ZipCPU|Laptop has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga