[U-Boot] [PATCH v3 6/7] arm: add a common .lds link script

[Simon Glass]

Hi Albert,

On Tue, Feb 28, 2012 at 1:25 PM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Hi Simon,
>
> Le 21/02/2012 21:14, Simon Glass a écrit :
>>
>> Hi Albert,
>>
>>
>> On Tue, Feb 21, 2012 at 11:52 AM, Albert ARIBAUD
>> <albert.u.boot at aribaud.net>  wrote:
>>>
>>> Hi Simon,
>>>
>>> Le 21/02/2012 18:02, Simon Glass a écrit :
>>>
>>>
>>>>>> +       . = ALIGN(4);
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This "ALIGN(4)" is what upsets my edminiv2 build and makes it not
>>>>> binary-identical. It is not in the current arm926ejs liner script. I
>>>>> will
>>>>> check if adding it to the current arm926ejs script produces a working
>>>>> and
>>>>> binary-identical u-boot.
>>>>
>>>>
>>>>
>>>> OK, but realistically we copy a word at a time (at least) and the
>>>> .rel.dyn region is going to be word-aligned I think. All we are doing
>>>> here is making sure that the image ends on a word boundary, which
>>>> seems reasonable to me.
>>>>
>>>> In other words, I would like the __image_copy_start and
>>>> __image_copy_end symbols to be word-aligned.
>>>
>>>
>>>
>>> I understand the requirement and agree to it -- only, it seems to me it
>>> is
>>> already fulfilled in the current lds files, so I still fail to see what
>>> breaks 'near binary identity'.
>>
>>
>> If we add any symbols or change the value of any of them, then the
>> binary file may change. You can see the differences by doing something
>> like:
>
>
> This statement is true in a very general fashion, but becomes false for many
> cases, including the one where the symbol is added at link stage and not
> referenced in the build, which is the case for edminiv2. Then the ELF file's
> symbol sections may change, but the .text and .data sections have no reason
> to.

I agree with that. But do you see this behaviour? I did initially,
until I realized that it was just that '-dirty' was be appended to the
version string, which was increasing the .rodata size and just
changing all the offsets in the text section. Once I committed the
change and rebuilt, the problem went away.

Please can you confirm what differences you are seeing with things like:

 armv7a-cros-linux-gnueabi-objdump -h u-boot
 armv7a-cros-linux-gnueabi-objdump -t u-boot
 armv7a-cros-linux-gnueabi-objdump -d u-boot
...


>
> Plus, you did not address my note that the current .lds already aligns the
> start and end of copy section to a multiple of 4.

I think I missed that comment. I saw that you said that the ALIGN
before __image_copy_end was not in the arm926-ejs link script, but
when I looked I did in fact see it, e.g. in e37ae40:

arch/arm/cpu/arm926ejs/u-boot.lds:
...
	. = .;
	__u_boot_cmd_start = .;
	.u_boot_cmd : { *(.u_boot_cmd) }
	__u_boot_cmd_end = .;

	. = ALIGN(4);
        ^^^^^^^^^^^^^

	.rel.dyn : {
...


In the link script in this patch I have:


	. = ALIGN(4);

	. = .;
	__u_boot_cmd_start = .;
	.u_boot_cmd : { *(.u_boot_cmd) }
	__u_boot_cmd_end = .;

	. = ALIGN(4);

	__image_copy_end = .;

	.rel.dyn : {
		__rel_dyn_start = .;


Granted, the last ALIGN should not be needed since the size of
commands should be word-aligned anyway, and the first command is
clearly word-aligned, but it does make things clear I think. Can you
please explain more what you mean by ' the current .lds already aligns
the start and end of copy section to a multiple of 4'. And also, how
you would like me to change this patch. Just remove the last ALIGN?

>
>
>> armv7a-cros-linux-gnueabi-objdump -b binary -m arm -D u-boot.bin
>>
>> on each file (but I guess you know that).
>
>
> Yes, plus 'od -t x1z -A x u-boot.bin > u-boot.lst' :) and it does not
> explain why the .text and .data sections should undergo any change when the
> .lds introduces a symbol that neither section references.

See my note above about 'dirty', but if you are saying it is due to
the ALIGN, I am not sure what to say. I don't see that, so perhaps it
is best to email the commands you are using so I can replicate.

Regards,
Smion

>
>
>> Regards,
>> Simon
>
>
> Amicalement,
> --
> Albert.