This is the mail archive of the
mailing list for the binutils project.
Re: [GOLD] -Ttext does not relocate as expected
- From: ryan <stdstack at gmail dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Wed, 20 Mar 2013 18:10:03 -0700
- Subject: Re: [GOLD] -Ttext does not relocate as expected
- References: <CAOjn=HQxudFLCpUJqKw3jtBirW6X=nxUQPC4tGJDSW5=LD0jTQ at mail dot gmail dot com> <CAKOQZ8ytZu0iAOMoHqLF5q7nm8WRW1VUjv1GgRbns5cTy1+JEg at mail dot gmail dot com> <CAOjn=HQzvXgkaPpAaGbB-TbGQQHektrfMfdtA9wkaHw7xsS+aQ at mail dot gmail dot com> <CAKOQZ8x2sg1MEoaD_BvTFkAZHwxvjj1O5o_0GYVYFAsifYb4FA at mail dot 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
.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:
[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)"
On Wed, Mar 20, 2013 at 5:51 PM, Ian Lance Taylor <firstname.lastname@example.org> wrote:
> On Wed, Mar 20, 2013 at 5:44 PM, ryan <email@example.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.
>> On Wed, Mar 20, 2013 at 5:33 PM, Ian Lance Taylor <firstname.lastname@example.org> wrote:
>>> On Wed, Mar 20, 2013 at 5:21 PM, ryan <email@example.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
>>> 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.