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

[ryan <stdstack at gmail dot com>]

Thanks for your replay Ian! I tried your suggestions. Looks like
nothing suspicious to me.
Output of memory map:
> "Memory map

.text           0x00008c00      0x200
 .text          0x00008c00      0x200 boot.o
                0x00008c00                start

.data           0x00008e00        0x0
 .data          0x00008e00        0x0 boot.o

.bss            0x00008e00        0x0
 .bss           0x00008e00        0x0 boot.o"

Output of readelf:
> " There are 8 section headers, starting at offset 0x37c:
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00008c00 000054 000200 00  AX  0   0  4
  [ 2] .data             PROGBITS        00008e00 000254 000000 00  WA  0   0  4
  [ 3] .bss              NOBITS          00008e00 000254 000000 00  WA  0   0  4
  [ 4] .note.gnu.gold-ve NOTE            00000000 000254 00001c 00      0   0  4
  [ 5] .symtab           SYMTAB          00000000 000270 000090 10      6   5  4
  [ 6] .strtab           STRTAB          00000000 000300 000036 00      0   0  1
  [ 7] .shstrtab         STRTAB          00000000 000336 000043 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)"


-Ryan
On Wed, Mar 20, 2013 at 5:51 PM, Ian Lance Taylor <iant@google.com> wrote:
> 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