From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Fri, 10 May 2013 19:15:46 +0200 Subject: [U-Boot] [PATCH] avr32: fix relocation address calculation In-Reply-To: <1A284989-3691-4A1C-B79C-6BE55B50357A@prograde.net> References: <1368005117-8624-1-git-send-email-andreas.devel@googlemail.com> <20130510112444.4dca773f@lilith> <518CD291.703@gmail.com> <20130510170924.5d03c9b5@lilith> <1A284989-3691-4A1C-B79C-6BE55B50357A@prograde.net> Message-ID: <20130510191546.464c2892@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Michael, On Fri, 10 May 2013 13:02:57 -0400, Michael Cashwell wrote: > On May 10, 2013, at 11:09 AM, Albert ARIBAUD 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.