Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 22 14:47
    simonedegiacomi synchronize #22
  • Aug 20 16:50
    simonedegiacomi synchronize #22
  • Aug 20 11:58
    simonedegiacomi synchronize #22
  • Aug 19 14:18
    l-yc opened #23
  • Aug 19 13:05
    simonedegiacomi synchronize #22
  • Aug 19 12:25
    simonedegiacomi synchronize #22
  • Aug 19 12:24
    simonedegiacomi synchronize #22
Ahmad Fatoum
@a3f
This one's compiler has --with-abi=aapcs-linux added and --fpu=vfp removed.
Simone Degiacomi
@simonedegiacomi
image.png
Ahmad Fatoum
@a3f
meh.. @simonedegiacomi you got gdb or something to get some more info why it crashes?
Ahmad Fatoum
@a3f
An invalid system call number is punished by a seg fault as well IIRC, strace would show that. hmm.. I am recompiling again with a different uclibc config
Simone Degiacomi
@simonedegiacomi

meh.. @simonedegiacomi you got gdb or something to get some more info why it crashes?

I can't run gdb on the EV3, but I tried to run it on a raspberry (I know it's not the same architecture, but it semes to work). When running the program I get:

(gdb) run
Starting program: /tmp/hellow.elf 

Program received signal SIGSEGV, Segmentation fault.
x00011c68 in strchr ()
Ahmad Fatoum
@a3f
Great. Ok, I'll do hopefully the last toolchain build now and look into packaging that one as docker containers
Simone Degiacomi
@simonedegiacomi
which flags did you use for the build of hellow2?
Ahmad Fatoum
@a3f
@simonedegiacomi I tried the buildroot uclibc config, I am changing it a bit to always statically link now.
That way we shouldn't need -static
Simone Degiacomi
@simonedegiacomi
so you're going to use buildroot instead of ptxdist?
Ahmad Fatoum
@a3f
@simonedegiacomi The OSELAS problem was with the uclibc config, which I had based on a uClinuc config that wasn't compatible it seems. With this fixed, both work now.
I'd go with OSELAS/PTXdist. Less learning curve for me ^^'
Ahmad Fatoum
@a3f
@OurLordAndSaviorStickles Thanks by the way for the buildroot config. Very helpful to see what I was doing wrongly before : )
Simone Degiacomi
@simonedegiacomi
ok understood. thank you for trying the different configurations, I didn't know where to start. When you'll commit the new configuration I will run the build for the raspberry pi (I need the compiler for that), if it may be useful also for others I can share it
One is C and the other C++.
There isn't a shortage on cross-compilers for the raspberry pi, why do you want to build your own?
Simone Degiacomi
@simonedegiacomi
I don't need the crosscompiler for raspberry pi, I need the compiler that runs on raspberry pi to compile programs for EV3 😄

One is C and the other C++.

they both work :thumbsup:

Ahmad Fatoum
@a3f
@simonedegiacomi great :) they print to stdout correctly as well?
Simone Degiacomi
@simonedegiacomi
@a3f yes
image.png
Ahmad Fatoum
@a3f
You dont't need a cross compiler for that btw. Just use your normal gcc with -ffree-standing and link manually against uclibc
But ye if it works out of the boz+
X*, that's a tad nicer
Simone Degiacomi
@simonedegiacomi
I compiled gcc for rpi with buildroot and it works, I also tried to run a program built for ev3 on rpi and it works (this is why I tried with gdb before), but I didn't try to run a program compiled with gcc of rpi on ev3. Wouldn't there be problems with the old headers? That's why my idea now was to compile gcc with ptxdist on rpi. Am I missing something?
Simone Degiacomi
@simonedegiacomi
I just tried, but when compiling with -freestanding and against static uclibc the linker reports a lot of errors about missing VFP register. I think I will just build the toolchain with ptxdist, so it's the same version used on x86
Ahmad Fatoum
@a3f
The trick is to not use your headers, but those of the uclibc you buiild yourself. To have the compiler not use vfp, ty -mfloat-abi=softfp, but ye, a cross compiler that just works is better
Our Lord And Savior Stickles
@OurLordAndSaviorStickles
@a3f No problem! I don't know a whole lot about this stuff (yet), so I'm glad I could help!
Ahmad Fatoum
@a3f
@simonedegiacomi I've pushed my ptxdist setup to c4ev3/C4EV3.Toolchain. A binary release for Linux is also uploaded. I'll see what to do about other host systems.
Simone Degiacomi
@simonedegiacomi

Great, thank you!
I noticed that your configuration doesn't support pthread, am I right? I built the toolchain myself (on the rpi) and it works, I just changed these two lines in the configuration to also support pthread:

- PTXCONF_CROSS_GCC_THREADS_SINGLE=y
- PTXCONF_CROSS_GCC_THREADS="single"
---
+ PTXCONF_CROSS_GCC_THREADS_POSIX=y
+ PTXCONF_CROSS_GCC_THREADS="posix"

Last question: do you have any idea why the binaries built with this compiler weight more that the ones built with the buildroot compiler?
For the same program:
ptxbuild compiler: 1.2MB
builtroot compiler: 334KB

(same compiler flags: g++ main.cpp static-libstdc++ -std=c++11 -pthread -Os -fdata-sections -ffunction-sections, -Wl,--gc-sections)
Ahmad Fatoum
@a3f
@simonedegiacomi Try running arm-c4ev3-linux-uclibceabi-strip on both
Simone Degiacomi
@simonedegiacomi
@a3f after running that program:
ptxbuild compiler: 219KB
builtroot compiler: 183KB
now the difference is much smaller, which I think is acceptable, thank you!
Ahmad Fatoum
@a3f
@simonedegiacomi And does the pthread support work correctly? You probably want to add --enable-tls to the gcc configuration options as well, so you can have efficient thread local variables
I can add both if you can write a small program that does some thready and thready-local stuff and they work
@simonedegiacomi re executable size, could you also try by appending -s to the compiler command line and see the difference?
Simone Degiacomi
@simonedegiacomi
@a3f it seems to work, but my program is very simple: I have all the code that controls the robot in one thread and the second thread only continuously checks if the back button is pressed to exit the program
@a3f adding -s the size is 211KB, so even smaller
Simone Degiacomi
@simonedegiacomi
@a3f I can try with --enable-tls and then search/try to write a program that does some concurrency. I'll reply when the build finished and I have some results
Ahmad Fatoum
@a3f
@simonedegiacomi If you only care about the back button, I think signals may be better
We could even integrate this easily with the EV3-API
In the API init code we register a signal handler for SIGALRM that checks which polls for the back button and calls _Exit() if it was pressed.
and then we arrange for SIGALRM to trigger every second. Having pthreads, just to poll and exit, feels overkill.
Ahmad Fatoum
@a3f
seems we are using SIGALRM already for the timer API. hmm, ok pthread it is then
The back button handler thread can still exist within EV3-API though, if you'd like to submit it. I hope to find time to start reviewing the pending Pull requests on sunday. If I don't, then next week
Simone Degiacomi
@simonedegiacomi
@a3f you're right, I didn't think about the timer API. I will look into it, maybe we can avoid the thread, because I see that there are different arrays for callbacks.
For the pull request no problem, even if it is next week (I'm currently adding the support for the PixyCam sensor)