Re: [GOLD] -Ttext does not relocate as expected

[Ian Lance Taylor <iant at google dot com>]

On Wed, Mar 20, 2013 at 5:44 PM, ryan <stdstack@gmail.com> wrote:
> I see. Thanks Ian! It seems like my example only has one text section, so what
> could be the other sections occupying the first 0x1000 offset?

I don't know.  One way to find out is to pass -Map=foo.map option to
gold (or GNU ld).  It will create in foo.map a map that will show you
how the sections are laid out.

Or you could just run readelf -S on the output file, I suppose.

Ian


> On Wed, Mar 20, 2013 at 5:33 PM, Ian Lance Taylor <iant@google.com> wrote:
>> On Wed, Mar 20, 2013 at 5:21 PM, ryan <stdstack@gmail.com> wrote:
>>> Not sure whether this is a bug or not. When I'm writing a simple hello
>>> world boot loader, I tried to relocate the text section to 0x7c00 for
>>> convention. The assembly code is attached. I used the following
>>> command to compile it:
>>>> gcc -m32 -nostdinc -c -o boot.o boot.S
>>>> ld -m elf_i386 -N -e start -Ttext 0x7c00 -o boot.out boot.o
>>>> objdump -S boot.out > boot.asm
>>>> ...
>>>
>>> It doesn't work as expected. Then I checked boot.asm the actual start
>>> address is 0x8c00 instead of 0x7c00.
>>>> Disassembly of section .text:
>>>> 00008c00 <start>:
>>>>    8c00: fc                   cld
>>>>    8c01: 31 c0                 xor    %eax,%eax
>>>>    ...
>>>
>>> It took me a while to realize in my system, I replaced the default
>>> `ld' with `ld.gold'. So `ld' in the above command is actually
>>> `ld.gold'. After I changed it back to use the default `ld', the start
>>> address become 7c00 as expected. Does anyone has a clue why it's like
>>> this?
>>
>>
>> For GNU ld the -Ttext option sets the address of the .text section.
>> For gold the -Ttext option sets the address of the text segment.  If
>> your .text section is not the first section in your text segment, then
>> the results will differ.
>>
>> Ian