Recommendations for ARM compilers

We have found that ADS 1.1 is buggy, and the vendor's debugger is
really poor. ADS 1.2 did not fix these bugs.

Now that we've released the first model of the product, we have a
little time before additional models, new accessories, etc., and we
can investigate changing tools.

So I am interested in recommendations for commercial (not gcc, thank
you) C compiler and tool packages.

A few more specifics:

1. No ARM9 specific code is used, the binaries could run on an ARM7.

2. No Thumb code, full 32-bit all the way.

3. We own several Abatron BDI2000 Ethernet JTAG debuggers (and really
like them!), so we need tools that support it and allow programming
off-chip flash through the debugger.

I would appreciate any recommendations or experiences good or bad with
tool sets, we can check out the debugger and flash support issues with
the tool vendors.

Thanks,
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

You also can use realtime OS of their production.

Visit www.keil.com

Mickey

Just curious what's wrong with ADS 1.2? We have used it for a while
for quite a complex project and haven't seen any bugs.
Were we just lucky?

Have you tried the RVCT compilers? Specifically the latest versions?

-p
--
Paul Gotch
CoreSight Tools
Development Systems ARM Limited.

This message is intended for the addressee(s) only and may contain
information that is the property of, and/or subject to a confidentiality
agreement between the intended recipient(s), their organisation and/or the
ARM Group of Companies. If you are not an intended recipient of this
message, you should not read, copy, forward or otherwise distribute or
further disclose the information in it; misuse of the contents of this
message may violate various laws in your state, jurisdiction or
country. If you have received this message in error, please contact
the originator of this message via email and delete all copies of
this message from your computer or network, thank you.
---------------------------------------------------------------------

What kind of bugs? ADS1.2 was at the time a big quality improvement
over previous releases, and many people are still using it today despite
its age... (interestingly it still beats the latest GCC!)

I would try out its successor RVCT2.2 which gives an easy upgrade
path, especially if you're using any language extensions. It supports
full C++ which is something ADS wasn't very good at.

Wilco

Using ADS 1.2 (from ARM) on a complex ARM7 right now. Combination of
Multi-ice and BDI-2000's. Both worked fine until the hw engineers made some
board changes :(

Otherwise works fine. I have used another companies version of ADS 1.1 and
don't blame you for wanting to switch. You can buy the current ARM package
(I think they call it RealView now) and it comes with ADS 1.2 on a separate
CD.

Scott

>....

Jack, you may want to give our $199 ARM compiler a test drive. It's
fully functional for 45 days. As for debugger support, we emit Elf/Dwarf
and the current release has been tested with Nohau, Lauterbach, ADS,
etc. In our next update (probably next week), we will also have tested
it against Ashling, GNU Elf/Insight, and CrossStudio. So really, any
Elf/Dwarf debugger should work. Email me if you have any other questions.
--

// richard
http://www.imagecraft.com

I haven't been working much on the ARM code in the product, I've been
coding for a DSP on another board, but I do remember at least four
specific problems, and I can describe three of them.

1. We have a large application and as more of the features were added
and the number of source files grew, we ran into a linker problem. At
somewhere around (but not exactly) 256 files, somehow the linker
garbled one file name and threw out an error about being unable to
find the object file.

We fixed that one after I posted to these two groups and somebody
suggested linking each set of related files into a library, and having
a final link step that linked all the libraries. Since out
multi-tasking system is composed of about 35 individual tasks, each in
its own directory, we took that advice and it worked.

2. We had a real nasty problem with pointers to members of
structures. Our architecture, originally developed on a 32-bit x86
processor for a different RTOS, used message queues for inter task
communication. I'll show some simplifier code...

Each task defines a message enum:

enum TASK_TYPE { TIMER_MSG, DATA_UPDATE_MSG /* etc. };

...then a structure for the data of each message type:

struct timer_data { uint32_t token; uint32_t time; };
struct update_data { int32_t x_pos; int32_t y_pos; };
/* etc. */

...and finally its overall message structure:

struct my_msg
{
enum TASK_TYPE msg_type;
union
{
struct timer_data t_data;
struct update_data u_data;
};
};

A task blocks on a call to retrieve a pointer to a message structure
from its queue. When it has a message and it is the highest priority
task ready to run, that call returns, and it dispatches the message to
the proper handler function:

for ( ; ; )
{
struct my_msg *msg = rtos_get_message(queue_id);
switch (my_msg->msg_type)
{
case TIMER_MSG:
my_timer_handler(&my_msg->msg_data.t_data);
break;
case DATA_UPDATE_MSG:
my_update_handler(&my_msg->msg_data.u_data);
}
}

In other words, the handler function is called with a pointer to data
structure member of the union inside the message structure.

The ADS 1.1 compiler GOT THE ADDRESS WRONG. It was off by 4 or 8, I
forget which. We walked through the code at the assembly level with
the debugger. When it came to taking the address of a member of a
structure from a pointer to the structure, IT JUST PLAIN ADDED THE
WRONG OFFSET.

We did try ADS 1.2 on this one, and it had the same problem.

3. We only bumped into this one a few weeks ago:

enum ( FALSE, TRUE } bool_t;

void some_func(void)
{
bool_t some_name = FALSE;

if (/* some condition */ && /* some other condition */)
{
some_name = TRUE;
}

/* code */

if (bool_t)
{
/* code */
}
}

If I remember correctly, the initialization of some_name to FALSE (0),
did not happen. Unless the condition was true, setting it to TRUE
(1), it remain uninitialized and had random garbage in it.

So we had to change all code like that to this:

if (/* some condition */ && /* some other condition */)
{
some_name = TRUE;
}
else
{
some_name = FALSE;
}

We did not try ADS 1.2 on problems number 1 and 3, but it did not fix
number 2. At that point we had lost enough time to be seriously
behind schedule and decided we could live with the problems we knew
and had workarounds for. We didn't have time to try out other tools
and make a change without blowing the release data.

Now that version 1.0 went out the door on time, and we've got a little
breathing space, we want to evaluate other tool sets.

For reference from the compiler/linker point of view

ADS 1.1 -> ADS 1.2 -> RVCT 1.2 -> RVCT 2.0 -> RVCT 2.1 -> RVCT 2.2

So ADS 1.1 is 2 or 3 generations behind the current tools depending on how
you cound. A large number of new features have been added since ADS 1.1 and
lots of bugs have been fixed.

Did you report the problem to ARM? In any case this sounds as though it has
long since been fixed.

Again did you report the problem? Incorrect code generation bugs are taken
extremely seriously.

Again did you report the problem? This also sounds like it has long since
been fixed.

It would be to your loss to write off the ARM compiler based on your
experiences of ADS 1.1. Try RVCT 2.2 (part of RVDS 2.2) and report any
problems to ARM support.

-p
--
"What goes up must come down, ask any system administrator"
--------------------------------------------------------------------

[snip]

We bought the tools through an ARM reselling third-party, and ARM will
not support them directly when you do this. For a variety of reasons,
including the total incompetence of their support, we have decided
that we do not wish to continue dealing with this vendor.

ARM RVCT is quite expensive, and I am unsure about how well it will
work with our BDI2000 JTAG debuggers, which we are quite happy with
and not planning to replace.

You could always try gcc and the GNU toolchain. Get the source and compile
yourself (using either Cygnus libs or MingW on Windows), or visit
www.microcross.com for ready-to-go Windows binaries.

I'm using the Microcross tools, which came bundled with Netsilicon's Net+OS,
and I've never had any problems with them.

Mit freundlichen Grüßen

Frank-Christian Krügel

I've had excellent luck with IAR... Although expensive, they have
support beyond all others.

James Kosin

Thanks for the explanation, see my responses below.

I agree with Paul that it's best to report any bugs you find. Bugs in compilers
are generally very rare (MUCH rarer than the bugs in the code it is compiling,
more like 1 in a million rather than 1 in 1000), but they do occur in all.
Usually the first time I test a new compiler on my test suites I find several
problems - and that's just the internal errors or crashes while compiling the
code (not counting syntax errors as no 2 compilers accept identical syntax...).

Reporting bugs gives the vendor a chance to improve the quality of their
product, which in the end benefits all customers. You would typically be
given a workaround if there is any (which is safer and often less intrusive
than inventing your own workarounds). Many vendors supply free patch
releases which just contain bugfixes, so it is always recommended to
upgrade to the latest available.

This sounds like you ran into the command-line length limit in Windows.
The solution is to use via files which have no limit.

<sniped code example>

This sounds unlikely, if something as basic as taking the address of a structure
field would be wrong, not a lot of code would work (ADS1.2 is used in
many current mobiles, which do appear to work most of the time...). The
particular circumstances are most likely a lot more complicated than you
describe. Did you manage to narrow it down to a small example that
demonstrates the problem? I am interested in seeing it (apply the obvious
transformation to get my email address).

<snipped example>

Again it sounds unlikely the circumstances are as trivial as you describe.
Compilers don't remove initializations unless they are redundant. A far
more likely scenario is that the variable got corrupted later. Do you have
a small example for this one too?

Note there are several patch releases available for ADS1.1 and 1.2 on the
ARM website, so it would have been worth trying out those. If all that failed
and you couldn't get a satisfactory answer from your vendor, it would have
been reasonable to tell ARM support about your issues - I'm sure they would
be sympathetic.

Wilco

snip

I'd add a vote here for GNU and Microcross, I've been using their
distribution of the GNU tools for the ARM (and also for the SH) for several
releases (GNU 2.95.2 throgh 3.4) and their support has been excellent. I've
only found one bug which they confirmed and found a workaround for within 24
hours and corrected on their next release.

I've also used the tools from www.gnuarm.org as well without any problems
(but no support).

Stan Katz

Napi

I had a similar problem when a '_packed' qualifier was involved. The
structure
was declared as _packed and then a pointer to its member was passed
to a function as a parameter. Since the function knew nothing about
the _packed, it expected that 32-bit value to be aligned on a word
boundary,
which was not the case.
Rewriting the function declaration as void func(_packed uint32_t *)
solved
the problem.

surely taking the address of a _packed member should yield a _packed
pointer. passing that to a function requiring a non-packed pointer should
surely report a warning at least.

Peter

There was no warning. And it's a good question to compiler writers
whether it should have been there. AFAIK, this '_packed' thing
is not properly standardized.

Please can you ensure you don't remove the attribution lines ("xxx wrote:"),
as it makes the posts difficult to follow.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/

That's a very interesting idea, although completely impossible for my
situation for several reasons. The first is that the application runs
on our own real time kernel, and the effort to bring up a JVM is not
practical. Then there's the fact that we peak at about 90% CPU usage
with code written in compiled C with some assembly language in the
ISRs and kernel, so we'd never meet our timing requirements with Java
bytecode.

But I do appreciate your suggestion.

Actually it is an error to implicitly cast a packed qualified pointer to a
non-packed pointer. It would be a bug if it allowed you to pass a
packed pointer as if it weren't. Packed behaves a lot like a type
qualifier that sets the natural alignment to 1, so it is quite well specified.
No chance of it getting accepted as in the next C standard of course.

Wilco

Actually, surely on an architecture that has the concept of bus error
for unaligned accesses, like yours, packing of struct members that
moves elements to "illegal" addresses should plain and simply never
have been allowed in the first place.

I would say that using such a feature, you're firmly in "whatever
silly result you get is exactly what you asked for" territory.

--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

I don't know why you'd say that. The _packed qualifier is perfectly sensible
on such an architecture, and indeed is only meaningful on such an
architecture. It simply tells the compiler to use multiple individual byte
accesses for multi-byte data types.

This comes up, for instance, when accessing a FAT boot sector, which has
lots of unaligned fields. Without this feature, you have to do explicit byte
accesses in the C code, which is clumsy and bug-prone, and also needlessly
inefficient when compiled for a machine on which it isn't necessary. The
_packed attribute makes the compiler do the work for you, but only if the
architecture requires it.

To support this properly, the compiler must treat _packed as part of the
type, just like const or volatile, and complain about the use of a _packed
pointer when a normal one was expected.

--

Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com

In the embedded world it is an essential requirement for a compiler
to be able to pack structures, and most compilers implement it, so
this is standard stuff (even VC++ supports __unaligned).
The __packed qualifier is necessary if you want to take the address
of a packed field in a structure and pass it. Such an address is not
assignment compatible with the unpacked equivalent as they
use different natural alignments (like const, you can gain packed,
but not lose it).

Although the latest ARM architectures have unaligned support in
hardware, it is still useful to know which accesses are packed and
which aren't for optimization purposes.

If you explicitly cast a packed pointer to an unqualified one, then
yes you get what you asked for. But that is true for just about all
casts - the same happens when you cast a char pointer to an int
pointer. If you use __packed properly then it will work perfectly.

Wilco

Mmm, I have to admit I don't know how such a cast can be done.

That's exactly what happened.
Let's talk (pseudo)C:

typedef __packed struct
{
uint8_t a[n];
uint16_t field1;
uint16_t field2;
uint16_t field3;
} the_struct;

void update_field( uint16_t * );
...

the_struct THESTRUCT;

...

// This line does not generate any error/warning
update_field( &THESTRUCT.field1 );

Sorry, I didn't remove them, I just quoted manually.
Had to read Help to learn how to do this properly with Google Groups.

The google groups interface to usenet is seriously broken. However
you can do fairly well if you follow the instructions in my sig.
below.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

So you are using a non-portable, non-standard and dangerous construct and
the compiler doesn't warn of alignment issues when you do something with
it that violates the processors alignment restrictions.

Why do you feel the need to use packed in the first place? Every time
I've looked at it, it appeared to be far more trouble than it was worth.
Most of the adavantages of it appear to be illusory to me.

Robert

well, it's not my code. But it's a real life code, part of
the large software project that has been ported from an 8-bit
platform to ARM (and then from ADS 1.2 to GCC).

That's what I'm actually interested in: should there be a warning
for such a construct?

I don't feel the need for it at all in this particular example.
What seems to have happened is: in the process of porting
from 8-bit to 32-bit, it became clear that certain structures
has to be __packed (for whatever reason) to make the code work
correctly,
it was also considered worthwhile to apply __packed to all the
structures
in the project to save memory. Luckily, it was the only bug introduced
this way.

[and my apologies to the OP: my remark has led the discussion away from
the original goal (as it always happens in a newsgroup)]

A very bad idea if the structure already has aligned fields or the space
saving is very small. Most compilers will generate 4 byte accesses for a
32bit word in a packed structure, and performance will be abysmal.

There should not be one, there should be at least four:

1) the moment it saw "__packed", the compiler should have output a
"Danger Will Robinson! Needless loss of portability encountered!"
warning.

2) The moment it saw that the effect of __packed was to place any
structure field into a position inaccessible by an ordinary pointer,
it should have either refused to do that, or output another warning
"Potential loss of usability."

3) If it allowed misaligned elements, it should have refused to let
you take the address of such a thing, or printed yet another warning
"Unusable pointer value computed."

4) Even it did let you pass all the way through here, it should have
refused to let you assign this pointer as if it was a correct pointer
to an object, or output an other warning "Use of misaligned pointers
is almost guaranteed to fail."

One alternative that would allow to not issue warnings 2 to 4 would be
to make all C pointers inherently capable of addressing even
misaligned values, either by installing a CPU exception handler for
misaligned access that fixes it up, or by introducing an abstraction
layer between pointer values and actual addresses that checks every
pointer usage for possible misalignment. Both of these tend to be
performance desasters, so you don't really want to go down that road.

So the code in question does one questionable, one foolish, and one
completely crazy thing, in that order. Sometime between the
questionable and the foolish, the compiler made a decision that
exposes the last in the code's list of sins as the crazy thing it is,
and you say you want to be warned only when it's reached the "crazy"
stage. That's a strange view of the world you have there.

I say the compiler should have bluntly refused to cooperate at the
foolish step of taking the address of a packed structure element, and
given you a stern warning about the effects of its own decision
combined with the questionable use of __packed before that. Or it
should have simply not packed that densely. But then your ulterior
motive for using the __packed hack would have failed to work out,
wouldn't it?

Actually, from what you say, the only thing that became clear at that
point was that the 8-bit code was not particularly portable to begin
with, and that the people who ported it to ARM had no idea how to
*properly* fix that problem once and for good. __packed is hardly
ever the right way of doing that, because it's based on the
fundamentally wrong concept of equating internal data structures of a
C program with externally defined data exchange formats.

That was quite a silly idea, to put it mildly. What on earth would
you conserve individual bytes for, given that

1) the smallest memory chips you can easily get your hands on are a factor
of 4 larger than the entire supported address range of the previous CPU

2) the new CPU can address more memory than you can afford

3) the new CPU may kill your program on a misaligned access?

?

... the only one you've *found* so far. Absence of evidence is not
evidence of absence.

I won't ask you to defend it then ;)

Maybe. In fact my inclination would be that it should, but we are well
into implementation defined constructs here.

The biggest problem I see is that the only solutions appear to be
- a (yet another) keyword to indicate the pointer passed to the
routine may be unaligned. If done globally the cost of accessing via
pointers will have just gone through the roof. Can you say code bloat?
If done only on routines that get passed pointers to (potentially)
unaligned pointers, and you rely on the compiler to warn on those
instances you end up with a sort of creeping rot.
- Forbid passing pointers to structure members.
- Forbid passing unaligned pointers and rely on the compiler
warning about all the cases. That would make me a bit nervous but the
compiler might be up to it.
- Forbid passing unaligned pointers and rely on the user
recognizing the forbidden cases. You already know why you don't like
that one :)

Frankly I don't see any viable solution on an architecture with alignment
restrictions other than to forbid the use of packed. Or if you must use
packed forbid taking the address of member elements of packed structures.

Hmm, that strikes me as applying a non-standard keyword to cover up a bug
rather than fixing the bug in the first place.

Um, if they want to apply packed to all structure why not just tell the
compiler that rather than add the keyword to every structure. You are
much less likely to miss an instance that way. It still strikes me as a
bad optimization though, it takes more time and space to access unaligned
members.

Robert

Indeed, and for this reason it is generally a bad idea to pack all fields in
a structure. It is much better to pack just the fields that need to be packed.
This way most fields will be aligned to their natural alignment and thus
accessing them is efficient.

Packing all fields or assuming all pointers have lower than natural alignment
is only feasible on CPUs that have unaligned support in hardware, such as all
new ARM cores.

Wilco

> > the compiler doesn't warn of alignment issues when you do something with

No, there shouldn't be - it is an error. The example you gave produces a
compile-time error in ADS1.2 as expected. It is illegal to lose the packed
qualifier, but it is legal to gain it - it works just like const and volatile.

Wilco

The gcc documentation explicitly states that if the packed attribute
is used, that the resultant code is incompatible with code not using
the packed attribute. From compiling a number of examples it appears
as if all accesses to structures are made using byte accesses when
using the packed attribute. On the Philips LPC2xxx series of ARM MCUs,
many people uses structures to access the peripheral registers. The
code is completely broken when using the packed attribute.

Regards
Anton Erasmus

Here it gets interesting. I've just checked (had to ask my colleague
with yet unexpired ADS license) - and there's *no* warning or error.
ADS1.2 [Build 848].
The commandline is:
[-O0 -Otime -asm -Oautoinline -g+ -fs -Wq -Ec]

Could you quote the exact error message, please?

And thanks to all of you who produced such lengthy posts
explaining how stupid it is to use __packed ;-)
I can't afford replying to every post and don't feel it's
really necessary because I completely agree with you on most points.

I can assure you that the bug is about to be fixed properly :),
so the question is of purely academic interest.

tum_ wrote:

All right, looks like '-Ec' suppresses the error. Haven't tried
w/out it yet but the description in the docs gives a good hint
on this.
No bleeping idea who put it into the makefile and for what reason :)

Went to double-check the options used for gcc now.

Note that -O0 means that all optimizations are switched off (ie. slow&large
code), so -Otime has no effect.

> Well, obviously to get rid of the alignment errors, since they couldn't
> possibly be a problem ;)

Possibly. It is likely however that the code simply didn't compile
without ignoring illegal implicit casts - most code isn't even close to
being standards compliant, so all compilers accept quite loose C
by default, and have many options to accept even more arcane C.

Wilco

Well, obviously to get rid of the alignment errors, since they couldn't

Robert

I am very dappy with gcc. Lot of help available online on IRC, newsgroups and ML.

gcc: http://www.codesourcery.com/gnu_toolchains/arm/
(Bare Metal GCC for ARM)

> 1. No ARM9 specific code is used, the binaries could run on an ARM7.

use
-march=armv4 -mtune=arm9t
options

> 2. No Thumb code, full 32-bit all the way.

just use
-mno-thumb-interwork
option to forbide this :)

> 3. We own several Abatron BDI2000 Ethernet JTAG debuggers (and really
> like them!), so we need tools that support it and allow programming
> off-chip flash through the debugger.

so do I :)

just use the telnet version that supports gdb, and thats it.

> I would appreciate any recommendations or experiences good or bad with
> tool sets, we can check out the debugger and flash support issues with
> the tool vendors.

arm-none-eabi-as
is the assembler

arm-none-eabi-gcc
to compile

arm-none-eabi-ld
to link

arm-none-eabi-objcopy
to extract bits of code

arm-none-eabi-objdump
to examine the files

arm-none-eabi-gdb
to upload the data in the board through the network interface.

This can work using Linux or Windows. Since it is CLI, it isvery easy to write
scripts an automise procedures.

Since everything is text file in the source tree, it is trivial to use a versionning
system like subversion or CVS to allow sharing the development (even with multisite
developpers, so that many ppl can contribute to the code, but only my can test it in
the board), when the versionning systemallow to tag which version doeswhat, has
bugs, include reports and comments, and reload old version of the source tree.

I ve never seen versionning system for other project managers.

Note that my project is not exactly a standard free software project since it is
leaded by a company which pays some developpers.

Once Makefiles are written, after changing some line of code, just run 'make' to
recompile and upload the newcode in the board.

--
DEMAINE Benoit-Pierre (aka DoubleHP ) http://www.demaine.info/
\_o< If computing were an exact science, IT engineers would not have work >o_/