This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ld bug in the location counter calculation?


Hi Nick,

>
>> I have the following snippet in my linker script
>
>> ?__INIT_DATA_START__ = .;
>> ?.data __DATA_START__ : AT ( __INIT_DATA_START__ )
>> ?{
>> ? ?*(.data)
>> ? ?*(.data.*)
>> ? ?SORT(CONSTRUCTORS)
>> ?}
>> ?. = ALIGN(4);
>> ?__DATA_END__ = .;
>
>> However, as there isn't any real initialise data, the .data section is
>> empty. Looking at the code that it generates, __DATA_END__ has been
>> assigned an address that the same as __INIT_DATA_START__.
>>
>> From what I understand of the ld documentation, __DATA_END__ should be
>> the same as __DATA_START__
>
> Since the .data section is empty its start address is not used by the
> linker. ?Hence __DATA_END__ is the same as __INIT_DATA_START__. ?So
> basically the linker is behaving correctly.
>

Thanks for the answer. I guess my interpretation of the ld
documentation is incorrect.

So if the section is empty, the dot address is not adjusted. I have
interpreted that the dot address becomes _DATA_START_ even though the
section is empty as it would have been if the section was not empty.

What is the normal practice to force the dot address to be at
_DATA_END_ for both empty and non-empty sections?

For me, the main problem is that the c-runtime startup code uses
_DATA_START_ and _DATA_END_ in its calculation. With an empty section,
_DATA_END_ could be smaller than _DATA_START_.

Cheers,
Tehn Yit Chin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]