gcc: Thumb interworking and weakly linked functions

[Aneesh V]

Oops! Sorry. These mails skipped my Inbox and went into a sub-folder
in my mail client that I hadn't used for a long time. I didn't
realize that I had mails!

On Monday 20 February 2012 11:29 PM, Ulrich Weigand wrote:
> "V, Aneesh"<aneesh at ti.com>  wrote:
>
>> I agree that not marking the assembly functions ' %function' is a problem
>> in the code, so it's not a critical bug. But I would've been happier if
>> the linker refused to link it rather than branching with the wrong
>> instruction. Isn't that a problem?
>
> Well, if the target symbol of a branch is not marked as %function,
> the linker has no way of knowing whether that target is ARM or Thumb,
> so it cannot specifically error out if (and only if) the instruction
> is wrong.
>
> The linker *could* in theory give an error *unconditionally* whenever
> it detects a branch to a non-%function symbol.  The reason this is not
> done is probably for backwards compatibility with old hand-written code,
> say from an ARM-only era: branches to non-function symbols used to be
> allowed, and in fact work fine if all code is ARM-only.  Adding an error
> would break such old code.

Ok. Agree. I never used to use %function when I wrote assembly
functions earlier. I am sure a lot of code will break if this was
enforced.

>
>
>> Problem No:2
>> *************
>> Linaro GCC 2012.01 is giving a new problem w.r.to Thumb build
>> that is not existing in Sourcery G++ Lite 2010q1-202. However, I
>> couldn't reproduce this problem with a small program like above. So,
>> let me give you reference to the original u-boot code that shows the
>> problem and steps to reproduce it.
> [snip]
>> Please note that the .rodata symbols have odd addresses. These arrays
>> actually need to be aligned at least to half-word boundary. In fact, in
>> the image I verified that they are put at even addresses. So, the
>> symbols have been kept as real address +1.
>
> This seems strange.  How did you verify "that they are put at even
> addresses"?
> I can reproduce the odd addresses of .rodata symbols.  However, this
> occurs simply because the linker put *no* alignment requirement whatsoever
> on those sections:

Sorry, that was an error in interpreting the data. The data is put at
the odd address given in the map file.

>
> Section Headers:
>    [Nr] Name              Type            Addr     Off    Size   ES Flg Lk
> Inf Al
> [snip]
>    [11] .rodata.wkup_padc PROGBITS        00000000 000100 000004 00   A  0
> 0  1
>    [12] .rodata.wkup_padc PROGBITS        00000000 000104 000048 00   A  0
> 0  1
>    [13] .rodata.wkup_padc PROGBITS        00000000 00014c 00000c 00   A  0
> 0  1
>    [14] .rodata.wkup_padc PROGBITS        00000000 000158 000004 00   A  0
> 0  1
>
> Note the "Al" column values of 1.  In the final executable, those sections
> happen to end up immediately following a .rodata.str string section with
> odd
> lenght, and since they don't have any alignment requirement, they start out
> at an odd address.
>
> The reason for the lack of alignment requirement is actually in the source:
>
> const struct pad_conf_entry core_padconf_array_essential[] = {
>
> where
>
> struct pad_conf_entry {
>
>          u16 offset;
>
>          u16 val;
>
> } __attribute__ ((packed));
>
>
> The "packed" attribute specifies that all struct elements ought to be
> considered to have alignment requirement 1 instead of their default
> alignment.  Thus the whole struct ends up having alignment requirement 1;
> and since the section contains only a single variable of such struct
> type, this is then also the alignment requirement of the section.
>

Hmm.. Thanks. Removing packed seems to help. The following also helped.

@@ -34,7 +34,7 @@ struct pad_conf_entry {

  	u16 val;

-} __attribute__ ((packed));
+} __attribute__ ((packed)) __attribute__ ((aligned(2)));

BTW, just for my understanding:
The effect of adding __attribute__ ((packed)) to a structure is
equivalent to adding it for each field in the structure, right? And
because the first field doesn't have any alignment requirement, the
struct also doesn't have any alignment requirement right?

Wonder why the issue never occurred until we started building in Thumb.

Thanks a lot for looking into this.

best regards,
Aneesh