Re: Querry.-- 2/5/01

[Nick Clifton <nickc at cambridge dot redhat dot com>]

Hi MNShukla,

> Note that if I compare the images we get variation as follows---
> 
> |----------|-------------| ------------------------- |
> | Address  | Image with  |  Image with |  Image with |
> |  in hex  | index 644   |  index 645  | index 646   |
> |----------|-------------|-------------| ------------|
> | 224      |   b8        |   ba        |  bc         |
> ------------------------------------------------------

Err, I am not quite sure what you are trying to show with this table.

> Now, if I compile init.c in arm-linux-gcc, and use the same range by
> the use of map, it works fine.

So presumably GCC and ADS are producing different instructions for the
code in this file.  If you add -S to the command line (of either gcc
or ADS) you should be able get their assembler output, which you can
then compare visually.
 
> What could be the problem?  Can any body give me some pointer ?

My guess, is that the ADS is generating code for an older ARM
processor, one which did not have half-word load and store
instructions.  Instead it may be making use of the feature of the ARM
core that allows unaligned word loads to rotate their values into the
correct place.  If, however, alignment checking is enabled in the
system control coprocessor, an alignment exception will be generated,
which would presumably result in a kernel panic.

If this is the case, there are a couple of things you could try.

  * Find out the command line switch to tell ADS which ARM processor
    you are actually using.

  * Edit your kernels and disable alignment checking.

I hope that this helps.

Cheers
        Nick