<aggi>
and now i see, the armv7 (EABI5) profile chosen with gcc doesn't match arm-tcc emitted EABI4 (armv6)
<aggi>
got a _userspace_ package set, which i wiped all c++ dependencies from, ~700 builds verified against gcc-4.7/c-only
<aggi>
and, with arm-tcc 320/700 build succeeded already
<aggi>
ideally, it will be possible to compile linux kernel with arm-tcc/arm64-tcc one day
<aggi>
and with uboot loader there will be some severe issues too, hooking into arm(64)-tcc
<mnemoc>
libv: around?
<aggi>
alltogether, arm-tcc support is decent, including armv6 hardfloat (didn't test softfloat yet which it supports too)
<aggi>
it's alot of work still, to fully stabilize an arm(64)-tcc toolchain for _userspace_; kernel and uboot are another milestone open for discussion elsewhere
<aggi>
i'll downgrade the profile to armv6-harfloat (certainly good enough with arm-tcc) and see what else passes then
<aggi>
the "fun" poject isn't limited to aarch32/64, although i test with aarch32 first
<aggi>
hence if there is any interest in seeing an arm(64)-tcc toolchain supported just let me know
<mnemoc>
libv, turl: maxima is having troubles according to CF so we need to resume the migration
moteen has quit [Remote host closed the connection]
cnxsoft1 has quit []
<aggi>
if i had known, i had stabilized the gcc-4.7 aarch32 toolchain for EABI4 first, not EABI5
<aggi>
won't be difficult, to roll-back aarch32 to a armv6/hardfloat toolchain/gcc-cross-compiler, since it is compatible with arm-tcc eabi4
paulk-bis has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
paulk-bis has joined #linux-sunxi
paulk-bis has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Read error: Connection reset by peer]
hlauer has quit [Ping timeout: 480 seconds]
sunshavi has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
sunshavi has joined #linux-sunxi
aggi has quit [Ping timeout: 480 seconds]
aggi has joined #linux-sunxi
moteen_ has joined #linux-sunxi
moteen has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has quit []
moteen_ has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
paulk-bis has joined #linux-sunxi
<aggi>
does -march=armv6j imply EABI version 4?
<aggi>
asking, because arm-tcc emits vfpv2/armv6/eabi4 and i want to keep this compatible with whatever gcc-4.7 has to emit
apritzel has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
<aggi>
greetings apritzel
<aggi>
chances are you missed some question
<aggi>
does -march=armv6j imply EABI version 4?
<aggi>
asking, because arm-tcc emits vfpv2/armv6/eabi4 and i want to keep this compatible with whatever gcc-4.7 has to emit
<apritzel>
aggi: I am not particularly interested in archaeology, but I would say that is independent and something to be configured as defaults when building the toolchain
<aggi>
apritzel: archeology?
<aggi>
i am on latest git HEAD of tinycc compiler
<aggi>
and the binaries it emits run just fine on some recent cortex a53 armv8a cpu
<aggi>
the reason i want to keep this compatible/interoperatble is this only:
<aggi>
i got a c-only toolchain system profile here (compiled with gcc-4.7 for armv7 up until recently), and now swap GCC against tinycc
<aggi>
tinycc already succeeded with 320/700 ebuilds of the _userspace_ parts, and i expect some blockers to retain gcc/binutils with
<aggi>
and to mix compiler/linker of gcc and tinycc while testing i hit some other iregularities
<aggi>
such as, how to tell GCC to emit exaclty this: armv6/vfpv2/eabi4; to remain stable and safe
<karlp>
what's the goal here, using gcc 4.7, or using tiny cc?
moteen has joined #linux-sunxi
<aggi>
the goal is: removal of all c++ (hence gcc-4.7 which was the last clean GNU toolchain concerning this)
<aggi>
then next, wipe GNU toolchain and replace as much as possible with arm-tcc, in _userspace_ first, because reasons
<aggi>
and it seems, arm-tcc considered some particular abi stable, so i want to keep it at this with GCC too
<aggi>
and i had seen whan ebuild fail, dev-libs/libffi complaining about ABI mismatches, hence i want downgrade CBUILD to armv6 first
<aggi>
an
<aggi>
i'll simply test this, just sad, because the armv7 variant is stablized for almost one year now, and i didn't expect to hit yet another brickwall
moteen has quit [Ping timeout: 480 seconds]
<aggi>
-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard should do, it's the raspberry1 i think, which should be safe as far as vfpv2 instructions are concerned (which arm-tcc got support for)
<aggi>
not sure, if this could hit something not supported by armv8a/cortex-a53; i'll know tomorrow morning
<aggi>
still reports this: Tag_CPU_name: "7-A" ... Tag_FP_arch: VFPv3
<aggi>
with arm-tcc: Tag_CPU_name: "6" ... Tag_FP_arch: VFPv2 etc.
<aggi>
could be, the tagging is informational only, and code emitted doesn't contain imcompatible vfp instructions (just an example)
rajkosto has joined #linux-sunxi
rajkosto has quit []
vagrantc has quit [Quit: leaving]
<aggi>
same with -march=armv5 Tag_CPU_name is still 7-A
<aggi>
march=armv4, test binary reports vfpv3, impossible; either the reporting is wrong, or potentiall vfpv3 is emitted even when not desired, or both
<aggi>
all i know, when compiling libffi (required by python3), the build complained about some ABI mismatch
<aggi>
libffi compiled with arm-tcc
<aggi>
maybe it was using the libc.so from CBUILD, so given i am not concerned about a clean cross-compile yet, i want to tick down CBUILD to armv6/vfpv2/eabi4
<aggi>
which seems impossible, with gcc/binutils i got
<aggi>
strangely, hundreds of builds succeeded already, with arm-tcc, including a /bin/bash, and other monsters
<aggi>
karlp: the goal is, i want to compile/link/asm _everything_ with tinycc, kernel, libc, uboot-loader, and of cause the entire userspace
<aggi>
given the situation surrounding linux-kernel (vendor-locked against GCC and LLVM, both compilers written in c++ nowadays), uboot loader got some problematic dependency graph against python-swig (written in c++)