Bernhard, Carmelo, Khem, All, On Wednesday 05 January 2011 092303 Bernhard Reutner-Fischer wrote: > On Tue, Jan 04, 2011 at 09:30:21PM +0100, Carmelo Amoroso wrote: > >On 04/01/11 20:41, Yann E. MORIN wrote: > >> On Tuesday 04 January 2011 20:07:00 Khem Raj wrote: > >>> On Tue, Jan 4, 2011 at 10:18 AM, Yann E. MORIN > >>> <[email protected]> wrote: > >>>> Back some time ago, it had been discussed that it was up to the user to > >>>> properly configure his/her compiler to the desired target system: > >> [--SNIp--] > >>>> I'm ready to rebase this patchset in the near future (say, ready before > >>>> FOSDEM) if that is still deemed a good way to go. > >>> Please rebase and submit again. I will take a look at them > >Fine. At least this patch was useful to reopen that old thread ;-)
Yes, it's been a while that I had been sitting on this, and that it was lying somewhere on my HDD. I was always telling myself "OK, next WE, I'll update it and resubmit", and then, I had other things to do, and there it was yet postponed another week... Now, it on the rails, with ARM mostly converted (see below). > ISTR that SPARC was a bit tricky to get right. And I was told at the time that this had been solved on IRC: http://lists.uclibc.org/pipermail/uclibc/2010-January/043546.html <quote> I think what he means is that gcc doesn't provide explicit builtin_define's to let anyone but it know what version of the architecture is currently selected. So this breaks us selecting the correct optimized version of string and math functions. However after discussing on IRC, I think we can figure out what is selected implicitly via the builtin_define's it does provide to an acceptable level so that we won't break anything. </quote> I will dig in the archives when I'm back home tonight to see what the discussed solution was. > Overall we still want to > get rid of these mtune settings and rely on either the compiler to be > bootstrapped with the correct --with-cpu and --with-tune or flags to be > passed in via UCLIBC_EXTRA_CFLAGS. And by the way... One for you, Khem: For ARM we currently have a "use BX" option that when turned on uses BX to return from functions. From what I understand, BX is "Branch and eXchange", and is used to switch ARM <-> Thumb (based on low-order bits in the adress). So I believe this is usefull only when doing interworking, right? If the target is Arm-only mode, or Thumb-only mode, then there is no reason to use BX at all (although in Thumb-only, this might be the only way). Care to comment? I was thinking in changing this as thus: [ ] Use BX (if available) help If available on your target processor, use BX to return from functions. Say 'y' if you need to use interworking. Say 'n' if not. It is safe to say 'y' even if you're not doing interworking. And then detect availability of BX at build time, as per: http://lists.uclibc.org/pipermail/uclibc/2009-April/042301.html On the other hand, if BX is only used in case we're interworking, then we could/should rename the option to something like: [ ] Build interworking-safe functions. help Build a library whose functions are safe to call from interworking context. This will use BX to return from functions (if your target processor has it). And in the code, detect if BX is available, and #error out if not and the user asked interworking. Any comments? Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< O_o >==-- '------------.-------: X AGAINST | /e\ There is no | | http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. | '------------------------------'-------'------------------'--------------------' _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
