Utility Libraries for BREW-Compilation Pitfalls

Abstract

This article describes possible problems encountered when compiling the BREW utility library using ARM ADS1.x compilers and how to avoid them. An ADS1.0.1 conformant library is attached for downloading.

Problems

There are basically three main problems (numbers 3 and 4 have the same cause):

Cause and Cure

The linkage disagreement is mainly due to the fact that the global overload of operator new & delete on ARM is defined as:

void* operator new (size_t size);
void operator delete (void *p);

As a quick reminder, operator new & delete can be overloaded at global or on a per-class basis, as in:

class C
{
public:
C();
~C();
static void* operator new (size_t size); 
static void operator delete (void *p);
};

There are obvious disadvantages in using class level in BREW (what happens with POD?); the global alternative is preferred. The only problem with the global approach is when the overload is referenced from more than one translation unit, resulting in compilation errors on ARM. As static cannot be used, we can use inline, as in this code snippet:

typedef unsigned int UINT;
  inline void* operator new(UINT size);
  inline void operator delete(void * ptr);

This is a non-standard use assuming internal linkage (the standard indicates that inline has external linkage, but there are not too many conformant compilers). It's interesting to notice that assuming 'unsigned long' for size_t results in a "Non-RWPI Section" linkage error.

An internal fault is more complicated because we are in the unchartered territories of template standardization. Basically, the cause is a minuscule default template parameter used in BrewString—and default parameters are not supported by ADS 1.x compilers. The following piece of code:

template <class T = int>
class X{}

generates the internal fault. The problem was solved (as well as other standard compliancy problems) in the newest released RealView Compilation Tools 2.0.

opPlusImpl errors are related to 'friend' support in ADS. opPlusImpl has to have the fully qualified name, as in:

friend BrewString<T> operator+ ( const T* lhs,
                                 const BrewString<T>& rhs )
  {
    return BrewString<T>::opPlusImpl(lhs, rhs);
  }

An interesting fact is that ADS has standard support for friend templates. See http://gcc.gnu.org/fom_serv/cache/32.html for a description.

As mentioned before, the new 2.0 compiler has important bug fixes, especially in templates support and has to be preferred for development. For compatibility, the attached code was compiled using ADS1.0.1 and BREW1.0 (that's why there are STRLOWER and STRUPPER definitions).

In Conclusion

I want to say "Thank you" to all the readers who diligently have tested the code. Your observations and suggestions are at the basis of this article.

About the Author

Radu Braniste is Director of Technology at Epicad. He can be contacted at rbraniste@epicad.com

# # #