This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)
On Fri, Apr 23, 2010 at 7:35 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Apr 23, 2010 at 7:12 AM, Ian Lance Taylor <iant@google.com> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>> It can get quite complicated. What if there is an input with
>>>
>>> ---
>>> ? ? ? .text
>>> ? ? ? .p2align 23
>>> foo:
>>> ? ? ? nop
>>> ---
>>>
>>> I think the best linker can do is to issue an error.
>>
>> As far as I know that case is already handled just fine. ?The
>> assembler should put the required alignment in the sh_align field of
>> the section header. ?The linker should honor that alignment when
>> setting the section address, and should also copy the alignment into
>> the p_align field of the program header.
>>
>> The case I just changed was where the alignment was not reflected in
>> any sh_align field, but was only due to use of ALIGN in a linker
>> script.
>>
>> What do you think will go wrong with the above? ?Is your concern that
>> the operating system will not be able to align the physical memory
>> address as required by the program header alignment? ?I don't see why
>> that would matter on a virtual memory system.
>>
>
> Gold generates:
>
>
> It doesn't look right to me:
>
> 1. foo isn't aligned at 1<<14 bytes.
> 2. -z max-page-size=0x1000 isn' honored on the last segment.
Wrong tests. Here is the right one
[hjl@gnu-6 alignment-2]$ cat foo.s
.text
.byte 0
.data
.p2align 14
foo:
.byte 1
[hjl@gnu-6 alignment-2]$ cat foo.ld
SECTIONS
{
.text : { *(.text) }
.data : { *(.data) }
.dynamic : { *(.dynamic) }
/DISCARD/ : { *(.*) }
}
[hjl@gnu-6 alignment-2]$ gcc -c foo.s
[hjl@gnu-6 alignment-2]$ ld.gold -z max-page-size=0x1000 -o libfoo.so
-T foo.ld foo.o
[hjl@gnu-6 alignment-2]$ readelf -Sl libfoo.so
~/bugs/binutils/alignment-2
File: libfoo.so
There are 6 section headers, starting at offset 0x4068:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .text PROGBITS 0000000000000000 00001000
0000000000000001 0000000000000000 AX 0 0 4
[ 2] .data PROGBITS 0000000000004000 00002000
0000000000002001 0000000000000000 WA 0 0 16384
[ 3] .symtab SYMTAB 0000000000000000 00004008
0000000000000030 0000000000000018 4 2 8
[ 4] .strtab STRTAB 0000000000000000 00004038
0000000000000005 0000000000000000 0 0 1
[ 5] .shstrtab STRTAB 0000000000000000 0000403d
0000000000000027 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Elf file type is EXEC (Executable file)
Entry point 0x0
There are 2 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000001000 0x0000000000000000 0x0000000000000000
0x0000000000000001 0x0000000000000001 R E 1000
LOAD 0x0000000000002000 0x0000000000004000 0x0000000000004000
0x0000000000002001 0x0000000000002001 RW 4000
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
gABI says:
---
p_align
As ``Program Loading'' describes in this chapter of the processor
supplement, loadable process segments must have congruent values for
p_vaddr and p_offset, modulo the page size. This member gives the
value to which the segments are aligned in memory and in the file.
Values 0 and 1 mean no alignment is required. Otherwise, p_align
should be a positive, integral power of 2, and p_vaddr should equal
p_offset, modulo p_align.
----
I am not sure it is a good idea to have different p_align.
--
H.J.