This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Specific location for kernel_mutex.o : linker file issue. Need help !
- From: Guillaume Aymard <gaymard at scmmicro dot fr>
- To: Robin Randhawa <robin dot randhawa at gmail dot com>
- Cc: Andrew Lunn <andrew at lunn dot ch>, ecos-discuss at ecos dot sourceware dot org
- Date: Mon, 22 May 2006 10:05:37 +0200
- Subject: Re: [ECOS] Specific location for kernel_mutex.o : linker file issue. Need help !
Hi Robin,
Actually, I understand the use of the linker script, but to resume you
example
below, if "start.o" is in an archive, the the linker pretends it cannot
find it. This is my problem.
It looks like when archived, the object file boudaries vanishes and each
functions live theire own life
with theire .data, .text and .bss sections and their weird new symbolic
name.
The solution proposed by Andrew works, but on a per-function name basis. I
can specify the location
of a function with an obvious name (witch starts with Cyg_Mutex for
example) but if this function calls
another sub-routine which name is not so obvious, I can miss its
relocation. So if we find a way to relocate
an archived object file in the way you propose, I'll be glad, but it seems
that we can't :-( .
Regards,
Guillaume
Robin Randhawa
<robin.randhawa@g
mail.com> To
ecos-discuss@ecos.sourceware.org
21/05/2006 08:18 cc
Andrew Lunn <andrew@lunn.ch>,
Guillaume Aymard
<gaymard@scmmicro.fr>
Subject
Re: [ECOS] Specific location for
kernel_mutex.o : linker file issue.
Need help !
Hi Andrew, Guillaume.
Don't know if this helps but linker scripts can be used to direct the
linker
to place text from a particular object file in a particular order within a
section.
Here's a simplistic script which would place the text [code] components of
a
start.o object at the start of the .text section:
SECTIONS
{
.text : {
start.o
*(.text)
}
.data : { *(.data) }
__bss_start = .;
.bss : { *(.bss) }
__bss_end = .;
}
Maybe Guillaume could get away with adding the object files of interest
into a
separate section which could be located in the 16k iram without any code
changes, only linker script changes ?
Cheers,
Robin
On Wednesday 17 May 2006 15:49, Andrew Lunn wrote:
> On Wed, May 17, 2006 at 11:00:53AM +0200, Guillaume Aymard wrote:
> > This is not really the same issue, as I want to locate eCos's code
> > globally whithout knowing individally
> > which functions to locate in my iram region. And I don't want to edit
> > kernel's code with __attributes__ directives before each
> > functions. I'm not even sure it will work for a function. It will be
more
> > convenient for me to only modify the linker script. My aim is to
> > make several tests by filling my 16k fast ram chunk with different
> > kernel's component and measure the benefit.
> > I think it is possible to do this only using linker scripts. The
problem
> > is that the linker seems unable to extract an object file from the
> > archive to locate its .text sections in a specific location, although
it
> > can do this with an object file which is not in an archive. I don't see
> > why it can't. Are there linking limitations as soon as an object file
is
> > archived in a library ?
>
> I don't think the linker works with object files. It works with
> sections. Each function is in its own section and you need to specify
> the name of the section.
>
> ~/eCos/work/kernel/current/src/sync$ arm-elf-objdump --headers
> kernel_mutex.o
>
> kernel_mutex.o: file format elf32-littlearm
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .text 00000000 00000000 00000000 00000034 2**0
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 1 .data 00000000 00000000 00000000 00000034 2**0
> CONTENTS, ALLOC, LOAD, DATA
> 2 .bss 00000000 00000000 00000000 00000034 2**0
> ALLOC
> 3 .debug_abbrev 00000552 00000000 00000000 00000034 2**0
> CONTENTS, READONLY, DEBUGGING
> 4 .debug_info 00003af6 00000000 00000000 00000586 2**0
> CONTENTS, RELOC, READONLY, DEBUGGING
> 5 .debug_line 00001096 00000000 00000000 0000407c 2**0
> CONTENTS, RELOC, READONLY, DEBUGGING
> 6 .text._ZN9Cyg_MutexC2Ev 0000004c 00000000 00000000 00005114 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 7 .text._ZN9Cyg_MutexC1Ev 0000004c 00000000 00000000 00005160 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 8 .text._ZN9Cyg_MutexC2ENS_11cyg_protcolE 0000005c 00000000 00000000
> 000051 ac 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 9 .text._ZN9Cyg_MutexC1ENS_11cyg_protcolE 0000005c 00000000 00000000
> 000052 08 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 10 .rodata._ZZN9Cyg_MutexD1EvE19__PRETTY_FUNCTION__ 00000018 00000000
> 0000000 0 00005264 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 11 .rodata 000001e8 00000000 00000000 0000527c 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 12 .text._ZN9Cyg_MutexD2Ev 000000c8 00000000 00000000 00005464 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 13 .text._ZN9Cyg_MutexD1Ev 000000c8 00000000 00000000 0000552c 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 14 .text._ZNK9Cyg_Mutex10check_thisE21cyg_assert_class_zeal 000000cc
> 00000000 00000000 000055f4 2**2
>
> So try specifiying .text._ZN9Cyg_MutexD1Ev, .text._ZN9Cyg_MutexD2Ev
> etc in your linker script.
>
> Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss