This is the mail archive of the
ecos-bugs@sources.redhat.com
mailing list for the eCos project.
[Bug 19787] New: [Config tool] Several bugs around Memory Layout Tool
- From: bugzilla-daemon at ecoscentric dot com
- To: ecos-bugs at sources dot redhat dot com
- Date: Thu, 24 Apr 2003 15:57:56 +0100 (BST)
- Subject: [Bug 19787] New: [Config tool] Several bugs around Memory Layout Tool
http://bugs.ecos.sourceware.org/show_bug.cgi?id=19787
Summary: [Config tool] Several bugs around Memory Layout Tool
Product: eCos
Version: 0.2
Platform: All
OS/Version: HostOS: All
Status: ASSIGNED
Severity: normal
Priority: normal
Component: MLT
AssignedTo: jld at ecoscentric dot com
ReportedBy: akira dot yokosawa at toshiba dot co dot jp
1) LOADADDR forward reference error can sometimes happen.
2) ".rel.dyn" section is referred to as ".rel_dyn" in
mlt_tx39_jmr3904_r?m.mlt and .ldi.
This will cause an undefined section error if .rel_dyn is referred to in
the FOLLOWING() macro.
3) VMA address specified as absolute is not reflected in the final
object.
When VMA address is specified as absolute address, SECTION_xxxx
macro is output as:
SECTION_text (rom, 0x1, 0x10000, LMA_EQ_VMA)
In this case ".text" section has an absolute VMA address of 0xbfc10000.
Resulting target.ld contains a section definition of
.text : { . = 0x10000 ; . = ALIGN ( 0x1 ) ; ...[snip] } > rom
But in the resulting object, ".text" section is allocated at the end
of the previous section, and it has an empty area of 0x10000 byte at
its head. I'm not sure if this is a bug of ld or not.
In my limited knowlegde of ld script, when you want to specify an
absolute start address to a section, you should define as
.text 0xbfc10000 : { . = . ; . = ALIGN ( 0x1 ) ; ...[snip] } > rom
How-To-Repeat:
1) In Configuration Tool, select TX39 rom startup hal option.
2) Save the modified configuration to a new build tree.
3) Open the Memory Layout Tool.
4) Create a new memory region with the properties of:
Name: cache_rom
Start address: 9fc00000
Size: 80000
Don't check the "read only" check box.
5) Tentatively disable the relocation of "data" section.
6) Change the properties of "text" section:
VMA Absolute 9fc01000
Enable "Relocate section"
LMA Absolute bfc01000
7) Change the properties of "fini" section:
Enable "Relocate section"
LMA Following: text
8) Change the properties of "rodata" section:
Enable "Relocate section"
LMA Following: fini
9) Change the properties of "rodata1" section:
Enable "Relocate section"
LMA Following: rodata
10) Change the properties of "fixup" section:
Enable "Relocate section"
LMA Following: rodata1
11) Change the properties of "rel_dyn" section:
Enable "Relocate section"
LMA Following: fixup
12) Change the properties of "gcc_except_table" section:
Enable "Relocate section"
LMA Following: rel_dyn
13) Change the properties of "data" section:
Enable "Relocate section"
LMA Following: gcc_except_table
14) Save the configuration
15) Build the kernel
16) Try to build the kernel test program by the command at the top of
Build Tree.
$ make -C kernel/v1_2/tests
The make will fail with the error message from ld:
LOADADDR forward reference of section .gcc_except_table
collect2: ld returned 1 exit status
This is problem 1).
17) Remedy the above program by manually editing target.ld
Move section definitions of "data" and "bss" to just after that of
"gcc_except_table".
18) Try again to make tests.
$ make -C kernel/v1_2/tests
The make will fail again with the error from ld:
LOADADDR uses undefined section .rel_dyn
collect2: ld returned 1 exit status
This is problem 2).
19) Remedy the above problem by manually editing target.ld again.
Modify the output section name of ".rel.dyn" to ".rel_dyn".
20) Try again to make tests.
$ make -C kernel/v1_2/tests
Now the make will go well.
21) Check the allocated addresses of sections in the final object in
install/tests/kernel.
$ mips-tx39-elf-objdump -h bin_sem0.exe
will show something like:
bin_sem0.exe: file format elf32-bigmips
Sections:
Idx Name Size VMA LMA File off Algn
0 .rom_vectors 00000218 00000000bfc00000 00000000bfc00000 00008000 2**0
CONTENTS, ALLOC, LOAD, CODE
1 .text 00005ed4 000000009fc00000 00000000bfc01000 00001000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .fini 00000000 000000009fc05ed4 000000009fc05ed4 00008218 2**0
CONTENTS
3 .rodata 000003f4 000000009fc05ed8 00000000bfc06ed8 00006ed8 2**3
CONTENTS, ALLOC, LOAD, DATA
4 .rodata1 00000000 000000009fc062cc 000000009fc062cc 00008218 2**0
CONTENTS
5 .fixup 00000000 000000009fc062cc 000000009fc062cc 00008218 2**0
CONTENTS
6 .gcc_except_table 00000000 000000009fc062d0 000000009fc062d0 00008218 2**0
CONTENTS
7 .data 00000688 0000000080000200 00000000bfc072d0 00000200 2**3
CONTENTS, ALLOC, LOAD, DATA
8 .bss 00001a50 0000000080000890 0000000080000890 00000890 2**4
ALLOC
9 .debug_aranges 00000f38 0000000000000000 0000000000000000 00008218 2**0
CONTENTS, READONLY, DEBUGGING
10 .debug_pubnames 000032cd 0000000000000000 0000000000000000 00009150 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_info 0006d736 0000000000000000 0000000000000000 0000c41d 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_abbrev 00005a1a 0000000000000000 0000000000000000 00079b53 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_line 00011bc2 0000000000000000 0000000000000000 0007f56d 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_frame 00003504 0000000000000000 0000000000000000 00091130 2**2
CONTENTS, READONLY, DEBUGGING
Please look at VMA and LMA of "text" "rodata" sections.
VMA LMA
text 9fc00000 bfc01000
rodata 9fc05ed8 bfc06ed8
This allocation won't work if you want to use kseg0 and kseg1 segments
that shares physical address. This is problem 3).
You need to place them as follows:
text 9fc01000 bfc01000
rodata 9fc05ed8 bfc05ed8
If you only look at the "text" section, it would be all right if it
starts at 9fc00000 and has empty area of size 0x1000 at its head.
But that will affect the LMA address of the following section.
To remedy this, I manually edited the definition of .text section in
target.ld as:
.text 0x9fc01000 : AT (0xbfc01000) { . = . ; . = ALIGN ( 0x1 );
...[snip]
This modification will give a final section allocation of bin_sem0.exe
at my desire.
bin_sem0.exe: file format elf32-bigmips
Sections:
Idx Name Size VMA LMA File off Algn
0 .rom_vectors 00000218 00000000bfc00000 00000000bfc00000 00007000 2**0
CONTENTS, ALLOC, LOAD, CODE
1 .text 00004ed4 000000009fc01000 00000000bfc01000 00001000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .fini 00000000 000000009fc05ed4 000000009fc05ed4 00007218 2**0
CONTENTS
3 .rodata 000003f4 000000009fc05ed8 00000000bfc05ed8 00005ed8 2**3
CONTENTS, ALLOC, LOAD, DATA
4 .rodata1 00000000 000000009fc062cc 000000009fc062cc 00007218 2**0
CONTENTS
5 .fixup 00000000 000000009fc062cc 000000009fc062cc 00007218 2**0
CONTENTS
6 .gcc_except_table 00000000 000000009fc062d0 000000009fc062d0 00007218 2**0
CONTENTS
7 .data 00000688 0000000080000200 00000000bfc062d0 00000200 2**3
CONTENTS, ALLOC, LOAD, DATA
8 .bss 00001a50 0000000080000890 0000000080000890 00000890 2**4
ALLOC
9 .debug_aranges 00000f38 0000000000000000 0000000000000000 00007218 2**0
CONTENTS, READONLY, DEBUGGING
10 .debug_pubnames 000032cd 0000000000000000 0000000000000000 00008150 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_info 0006d736 0000000000000000 0000000000000000 0000b41d 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_abbrev 00005a1a 0000000000000000 0000000000000000 00078b53 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_line 00011bc2 0000000000000000 0000000000000000 0007e56d 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_frame 00003504 0000000000000000 0000000000000000 00090130 2**2
CONTENTS, READONLY, DEBUGGING
-----
End of PR
Originator:
Akira Yokosawa
Organization:
Toshiba
Audit-Trail:
Responsible-Changed-From-To: alexs->jld
Responsible-Changed-By: alexs
Responsible-Changed-When: Wed Apr 7 02:08:49 PDT 1999
Responsible-Changed-Why:
MTL PR, John to support.
From: "John Dallaway" <jld at cygnus dot co dot uk>
To: <bugs at cygnus dot com>
Cc: Subject: Re: ecos/19787: [Config tool] Several bugs around Memory Layout Tool
Date: Wed, 7 Apr 1999 11:46:58 +0100
This PR describes three distinct issues which are summarised at the
start of the report. I have confirmed that all three issues are indeed
problems. My analysis is as follows:
1) A forward reference error occurs when the LMA of a memory output
section X precedes that of section Y but the VMA of section Y precedes
that of section X. This scenario was analysed in the design phase of the
MLT but was not accommodated. In the general case, this problem cannot
be solved since it is not possible to use make forward declarations of
section names. However, it may be possible to improve the section
ordering algorithm to address the specific set of cases outlined in the
PR.
2) Output section 'rel.dyn' is a special case in that its name contains
a character which is illegal in a C pre-processor macro name. No other
linker-defined section names encountered to date exhibit similar
problems. This section name should be treated as a special case within
the MLT to ensure that the correct name is output as the parameter of
the FOLLOWING() macro.
3) The potential empty area at the start of a memory output section with
an absolute VMA may be eliminated in the way the PR originator suggests.
The problematic nature of the current implementation was not previously
appreciated. This would involve a simple, but highly pervasive change,
to the current MLT and SECTION_* macro argument list.
John Dallaway
From: "John D
From: "John Dallaway" <jld at cygnus dot co dot uk>
To: <bugs at cygnus dot com>
Cc: Subject: Re: ecos/19787: [Config tool] Several bugs around Memory Layout Tool
Date: Thu, 8 Apr 1999 16:03:26 +0100
Parts 2 and 3 of this PR are now fixed. Part 1 (forward references)
remains.
John Dallaway
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.