[U-Boot] [PATCH] avr32: fix relocation address calculation

[Albert ARIBAUD]

Hi Michael,

On Fri, 10 May 2013 13:02:57 -0400, Michael Cashwell
<mboards at prograde.net> wrote:

> On May 10, 2013, at 11:09 AM, Albert ARIBAUD <albert.u.boot at aribaud.net> wrote:
> 
> > The compiler considers the name/symbol to be value, not the address of the
> > corresponding object... at least most of the time: as you indicate, when
> > the symbol denotes a C array, then the C compiler understand the symbol as
> > the address of the array.
> 
> I ran into a case one on Codewarrior Mac PPC tools where there was a subtle
> different here. In an existing body of code there was originally a global
> char[] defined with a matching extern char[] declared in a header.
> 
> At some point the definition was changed to char* because the size of the
> array grew and we wanted it out of the global section. I traced an obscure
> crash to some assembly code that had worked when the definition was char[]
> but needed an extra level of indirection when it was char *.

Well, of course it did! char* is a pointer to char, with syntactic
facilities to use it as a pointer to char array, but char* is not an
array. The value of a pointer to char is a (probably 32-bit) address,
and you need to dereferenc it to get a char.

> During that debugging I found that the declaration had not been changed to
> char * but the C compiler hadn't cared. It handled the mixed forms just fine
> despite the clear difference in the code.

Well, the compiler would not care that one C module would know the
symbol as char* and another one would know it as char[], since the
compiler treats compilation units completely independently. You would
end up using the same address space area for two different objects: an
array of chars, overlapped with a (probably 32-bit) pointer to char.

Where I worked up until recently, we had a 'coding rule' that required
us to always #include a module's .h file (its public interface) from
within its .c file (its implementation) if only to make sure the
compiler saw both the declarations and the definitions in a single
compilation unit, and would thus bark at us for screwing up between
declaration and definition.

> I surmised it was some subtle issue around PPC's handling of global data
> (or the Codewarrior PPC ABI) but still don't really know.

This has nothing to do with PPC or CW; this is just C working as
designed.

> -Mike

Amicalement,
-- 
Albert.