Re: gprof SEGV issue for GCC-4.5.X toolchain.

[Richard Earnshaw <rearnsha%arm.com@localhost>]

On 28/06/11 17:39, Matt Thomas wrote:
> 
> On Jun 28, 2011, at 3:48 AM, Richard Earnshaw wrote:
> 
>> On 27/06/11 19:53, Matt Thomas wrote:
>>> 
>>> Well, first of all, NetBSD doesn't use EABI.  That ABI derives
>>> from bpabi.h which isn't used by arm*-*-netbsdelf*.  So you've
>>> built the wrong compiler to use with NetBSD.
>>> 
>> 
>> Hmm, it really is about time that NetBSD moved to the EABI.  I
>> thought that we'd agreed at the time that the current ABI was
>> adopted that it was going to be transitional, not permanent.
> 
> I was actually thinking about using thumb2 for the newer processors.

Yes, that would be good (though the merit of the EABI is that you can
switch freely between ARM and Thumb(2) code at any function boundary).
On large applications there's generally a performance benefit from
having the higher code density that comes with Thumb2 (smaller cache
footprints).

> 
>> There are a number of benefits to moving: more efficient alignment
>> of larger data types; better C++ exception handling; better testing
>> of the compiler (everyone else builds and tests with the EABI these
>> days).
> 
> New ABI presents a problem with compatibility.  We still binary
> compatiblity so we will need use MKCOMPAT to build older versions as
> well as EABI and thumb2 variants.  What about arm26 support?  Does
> that just go away [not that I would mind if that happened]?

Or do what Linux did and start a new 'port'.  The EABI only works with
ARMv4T or later in practice and really needs v5 or later.  That means
most ARM9 chips and onwards.

> 
> One other issues is we are moving away from libgcc so any compiler-rt
> will need to be provide those routines.  I don't see a listing of
> those routine in bpapi.pdf

No, the rt-abi is a minimal set that all compilers can be expected to
provide; there isn't a requirement to stick just to that minimum set.
Compilers can and do provide additional routines (they have to for some
extensions).

> 
>> I don't see the day being far off when support for the old ABI
>> becomes deprecated in GCC -- that'll put NetBSD at a disadvantage
>> if it hasn't worked out a transition plan.
> 
> Sadly, that seems to happen more and more these days (older power
> support going away, etc.).
> 

We all have limited resources and things move on.  It's a question of
where those resources are best concentrated and supporting long obsolete
products is not one of them.  It's a tough world out there.

R.
>