* RE: [ECOS] forwarded message from Simpkins, Andy
@ 2001-08-17 9:24 Simpkins, Andy
2001-08-17 9:31 ` Jonathan Larmour
2001-08-17 10:13 ` Mark Salter
0 siblings, 2 replies; 18+ messages in thread
From: Simpkins, Andy @ 2001-08-17 9:24 UTC (permalink / raw)
To: Jonathan Larmour, Simpkins, Andy; +Cc: ecos-discuss
> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
> Sent: 17 August 2001 17:10
> To: Simpkins, Andy
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
>
>
> "Simpkins, Andy" wrote:
> >
> > Configuration of the system
> > Target Platform : Custom board (ARM7TDMI core)
> > Development Host: Windows NT 4 sp6, cygwin, eCos
> 1.3.1, GCC 2.95.2
> [snip]
>
> Perhaps just compile the whole file with -mlong-calls instead of the
> attribute.
Nope that gives the same result :-(
$ arm-elf-gcc *.o -L /i/eCOSbuilds/a163_install/lib/ -Ttarget.ld -nostdlib
-Xlinker -Map -Xlinker mapfile.txt -mlong-calls
main.o: In function `main':
main.o(.text+0x10): relocation truncated to fit: R_ARM_PC24
flash_query(void)
collect2: ld returned 1 exit status
what is ld trying to tell me with the truncated error message? I note that
this is in the function main NOT flash_query, is this significant?
Andy
>
> Jifl
> --
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44
> (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley ||
> Opinions==mine
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] forwarded message from Simpkins, Andy
2001-08-17 9:24 [ECOS] forwarded message from Simpkins, Andy Simpkins, Andy
@ 2001-08-17 9:31 ` Jonathan Larmour
2001-08-17 10:13 ` Mark Salter
1 sibling, 0 replies; 18+ messages in thread
From: Jonathan Larmour @ 2001-08-17 9:31 UTC (permalink / raw)
To: Simpkins, Andy; +Cc: ecos-discuss
"Simpkins, Andy" wrote:
>
> Nope that gives the same result :-(
>
> $ arm-elf-gcc *.o -L /i/eCOSbuilds/a163_install/lib/ -Ttarget.ld -nostdlib
> -Xlinker -Map -Xlinker mapfile.txt -mlong-calls
> main.o: In function `main':
> main.o(.text+0x10): relocation truncated to fit: R_ARM_PC24
> flash_query(void)
> collect2: ld returned 1 exit status
>
> what is ld trying to tell me with the truncated error message? I note that
> this is in the function main NOT flash_query, is this significant?
Because that's where the call to flash_query happens.
Perhaps this just wasn't possible with gcc 2.95.2, in which case your only
choice is to move to gcc 3.0.1.
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] forwarded message from Simpkins, Andy
2001-08-17 9:24 [ECOS] forwarded message from Simpkins, Andy Simpkins, Andy
2001-08-17 9:31 ` Jonathan Larmour
@ 2001-08-17 10:13 ` Mark Salter
1 sibling, 0 replies; 18+ messages in thread
From: Mark Salter @ 2001-08-17 10:13 UTC (permalink / raw)
To: Andy.Simpkins; +Cc: jlarmour, Andy.Simpkins, ecos-discuss
>>>>> Simpkins, Andy writes:
> main.o: In function `main':
> main.o(.text+0x10): relocation truncated to fit: R_ARM_PC24
> flash_query(void)
> collect2: ld returned 1 exit status
> what is ld trying to tell me with the truncated error message? I note that
> this is in the function main NOT flash_query, is this significant?
The linker is being asked to patch an opcode with the difference between
the PC and an address. The R_ARM_PC24 indicates the opcode needs a 24-bit
pc-relative offset. The long_call attribute should force gcc/gas to ask
for a 32-bit absolute address instead of pc-relative.
Here's what the gcc manual says:
`-mlong-calls'
`-mno-long-calls'
Tells the compiler to perform function calls by first loading the
address of the function into a register and then performing a
subroutine call on this register. This switch is needed if the
target function will lie outside of the 64 megabyte addressing
range of the offset based version of subroutine call instruction.
Even if this switch is enabled, not all function calls will be
turned into long calls. The heuristic is that static functions,
functions which have the `short-call' attribute, functions that
are inside the scope of a `#pragma no_long_calls' directive and
functions whose definitions have already been compiled within the
current compilation unit, will not be turned into long calls. The
exception to this rule is that weak function definitions,
functions with the `long-call' attribute or the `section'
attribute, and functions that are within the scope of a `#pragma
long_calls' directive, will always be turned into long calls.
--Mark
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [ECOS] forwarded message from Simpkins, Andy
@ 2001-08-20 8:47 Simpkins, Andy
0 siblings, 0 replies; 18+ messages in thread
From: Simpkins, Andy @ 2001-08-20 8:47 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: ecos-discuss
OK thanks for the advice,
I have a workaround at the moment and shall try gcc 3.0.1 when available on
general release..
Thank you for your time
Andy
> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
> Sent: 20 August 2001 14:25
> To: Simpkins, Andy
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
>
>
> "Simpkins, Andy" wrote:
> >
> > Hi there,
> >
> > You suggested using GCC 3.0.1, obviously this is available,
> however the GNU
> > website doesn't appear to have links to it! It was due for release
> > 01-08-2001 but has been delayed - is there any other way to
> get a copy?
>
> It was meant to be out this weekend but has been delayed. And
> it look like
> their snapshot generation is currently broken :-|. That means the only
> thing to do right now hs check out of their CVS:
> http://gcc.gnu.org/cvs.html
>
> Remember to check out using "-r gcc-v3_0-branch" to get the
> 3.0 release
> branch (where 3.0.1 is coming from) rather than the trunk.
>
> Jifl
> --
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44
> (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley ||
> Opinions==mine
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] forwarded message from Simpkins, Andy
2001-08-20 1:12 Simpkins, Andy
@ 2001-08-20 6:25 ` Jonathan Larmour
0 siblings, 0 replies; 18+ messages in thread
From: Jonathan Larmour @ 2001-08-20 6:25 UTC (permalink / raw)
To: Simpkins, Andy; +Cc: ecos-discuss
"Simpkins, Andy" wrote:
>
> Hi there,
>
> You suggested using GCC 3.0.1, obviously this is available, however the GNU
> website doesn't appear to have links to it! It was due for release
> 01-08-2001 but has been delayed - is there any other way to get a copy?
It was meant to be out this weekend but has been delayed. And it look like
their snapshot generation is currently broken :-|. That means the only
thing to do right now hs check out of their CVS:
http://gcc.gnu.org/cvs.html
Remember to check out using "-r gcc-v3_0-branch" to get the 3.0 release
branch (where 3.0.1 is coming from) rather than the trunk.
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [ECOS] forwarded message from Simpkins, Andy
@ 2001-08-20 1:12 Simpkins, Andy
2001-08-20 6:25 ` Jonathan Larmour
0 siblings, 1 reply; 18+ messages in thread
From: Simpkins, Andy @ 2001-08-20 1:12 UTC (permalink / raw)
To: Jonathan Larmour, Simpkins, Andy; +Cc: ecos-discuss
Hi there,
You suggested using GCC 3.0.1, obviously this is available, however the GNU
website doesn't appear to have links to it! It was due for release
01-08-2001 but has been delayed - is there any other way to get a copy?
Andy
> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
> Sent: 17 August 2001 17:31
> To: Simpkins, Andy
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
>
>
> "Simpkins, Andy" wrote:
> >
> > Nope that gives the same result :-(
> >
> > $ arm-elf-gcc *.o -L /i/eCOSbuilds/a163_install/lib/
> -Ttarget.ld -nostdlib
> > -Xlinker -Map -Xlinker mapfile.txt -mlong-calls
> > main.o: In function `main':
> > main.o(.text+0x10): relocation truncated to fit: R_ARM_PC24
> > flash_query(void)
> > collect2: ld returned 1 exit status
> >
> > what is ld trying to tell me with the truncated error
> message? I note that
> > this is in the function main NOT flash_query, is this significant?
>
> Because that's where the call to flash_query happens.
>
> Perhaps this just wasn't possible with gcc 2.95.2, in which
> case your only
> choice is to move to gcc 3.0.1.
>
> Jifl
> --
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44
> (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley ||
> Opinions==mine
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [ECOS] forwarded message from Simpkins, Andy
@ 2001-08-17 9:33 Simpkins, Andy
0 siblings, 0 replies; 18+ messages in thread
From: Simpkins, Andy @ 2001-08-17 9:33 UTC (permalink / raw)
To: Jonathan Larmour, Simpkins, Andy; +Cc: ecos-discuss
I shall try GCC 3.0.1 and let you know
Have a good weekend
Andy
> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
> Sent: 17 August 2001 17:31
> To: Simpkins, Andy
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
>
>
> "Simpkins, Andy" wrote:
> >
> > Nope that gives the same result :-(
> >
> > $ arm-elf-gcc *.o -L /i/eCOSbuilds/a163_install/lib/
> -Ttarget.ld -nostdlib
> > -Xlinker -Map -Xlinker mapfile.txt -mlong-calls
> > main.o: In function `main':
> > main.o(.text+0x10): relocation truncated to fit: R_ARM_PC24
> > flash_query(void)
> > collect2: ld returned 1 exit status
> >
> > what is ld trying to tell me with the truncated error
> message? I note that
> > this is in the function main NOT flash_query, is this significant?
>
> Because that's where the call to flash_query happens.
>
> Perhaps this just wasn't possible with gcc 2.95.2, in which
> case your only
> choice is to move to gcc 3.0.1.
>
> Jifl
> --
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44
> (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley ||
> Opinions==mine
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] forwarded message from Simpkins, Andy
2001-08-17 8:24 Simpkins, Andy
@ 2001-08-17 9:10 ` Jonathan Larmour
0 siblings, 0 replies; 18+ messages in thread
From: Jonathan Larmour @ 2001-08-17 9:10 UTC (permalink / raw)
To: Simpkins, Andy; +Cc: ecos-discuss
"Simpkins, Andy" wrote:
>
> Configuration of the system
> Target Platform : Custom board (ARM7TDMI core)
> Development Host: Windows NT 4 sp6, cygwin, eCos 1.3.1, GCC 2.95.2
[snip]
Perhaps just compile the whole file with -mlong-calls instead of the
attribute.
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [ECOS] forwarded message from Simpkins, Andy
@ 2001-08-17 8:24 Simpkins, Andy
2001-08-17 9:10 ` Jonathan Larmour
0 siblings, 1 reply; 18+ messages in thread
From: Simpkins, Andy @ 2001-08-17 8:24 UTC (permalink / raw)
To: ecos-discuss
Configuration of the system
Target Platform : Custom board (ARM7TDMI core)
Development Host: Windows NT 4 sp6, cygwin, eCos 1.3.1, GCC 2.95.2
This is the current test file I am using:
main.cpp (entire file)
/* INCLUDES */
#include <stdio.h> /* printf */
#include <string.h> /* strlen */
#include <cyg/kernel/kapi.h> /* All the kernel specific
stuff */
#include <cyg/io/io.h> /* I/O functions */
#include <cyg/hal/hal_arch.h> /*
CYGNUM_HAL_STACK_SIZE_TYPICAL */
#include <cyg/infra/diag.h> /* diag_printf */
#include <cyg/hal/t3.h> /* LED Control */
#include <stdlib.h>
void __attribute__ ((section (".2ram.flash_query"), long_call))
flash_query(void)
{
for (int i=0; i < 0xffff; i++);
}
extern "C" int main(void)
{
flash_query();
return 0;
}
the build process (with errors returned)
$ cd /z/TMCB/Build/ARM/eCos/app/testFLASH
$ rm *.o
$ arm-elf-gcc -c -I /i/eCOSbuilds/a161_install/include/
../../../../../source/app/testFLASH/*.cpp -fno-rtti -fno-exceptions
../../../../../source/app/testFLASH/main.cpp: In function `void
flash_query()':
../../../../../source/app/testFLASH/main.cpp:14: warning:
`long_call' attribute directive ignored
$ arm-elf-gcc *.o -L /i/eCOSbuilds/a161_install/lib/ -Ttarget.ld
-nostdlib -Xlinker -Map -Xlinker mapfile.txt
main.o: In function `main':
main.o(.text+0x10): relocation truncated to fit: R_ARM_PC24
flash_query(void)
collect2: ld returned 1 exit status
and to round things off the mods to arm.ld (extract) as suggested by
Jesper...
#define SECTION_data(_region_, _vma_, _lma_) \
.data _vma_ : _lma_ \
{ __ram_data_start = ABSOLUTE (.); *(.data*) *(.data1)
MERGE_IN_RODATA \
_GOT1_START_ = ABSOLUTE (.); *(.got1) _GOT1_END_ = ABSOLUTE (.);
\
_GOT2_START_ = ABSOLUTE (.); *(.got2) _GOT2_END_ = ABSOLUTE (.);
\
. = ALIGN (4); \
__DEVTAB__ = ABSOLUTE (.); KEEP (*(SORT (.devtab*)))
__DEVTAB_END__ = ABSOLUTE (.); \
__NETDEVTAB__ = ABSOLUTE (.); KEEP (*(SORT (.netdevtab*)))
__NETDEVTAB_END__ = ABSOLUTE (.); \
__CTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.ctors*)))
__CTOR_END__ = ABSOLUTE (.); \
__DTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.dtors*)))
__DTOR_END__ = ABSOLUTE (.); \
*(.dynamic) *(.sdata*) *(.sbss*) \
. = ALIGN (4); *(.2ram.*) } \
> _region_ \
__rom_data_start = LOADADDR (.data); \
__ram_data_end = .; PROVIDE (__ram_data_end = .); _edata = .;
PROVIDE (edata = .); \
PROVIDE (__rom_data_end = LOADADDR (.data) + SIZEOF(.data));
---
Transcomm UK Ltd. DDI : +44 (0)23 80662155
Yeoman Park Fax : +44 (0)23 80662120
Test Lane
Southampton www.transcomm.uk.com
SO16 9JX
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [ECOS] forwarded message from Simpkins, Andy
2001-08-17 7:42 Simpkins, Andy
@ 2001-08-17 7:46 ` David Airlie
2001-08-17 7:46 ` Mark Salter
1 sibling, 0 replies; 18+ messages in thread
From: David Airlie @ 2001-08-17 7:46 UTC (permalink / raw)
To: Simpkins, Andy; +Cc: Mark Salter, ecos-discuss
Do you have any forward declarations to it? i.e. declare function at top
of file to avoid warnings?
Dave.
On Fri, 17 Aug 2001, Simpkins, Andy wrote:
> Nope there are no header files associated with this - to keep bad header
> files out of the equation all of the code is resident in the file main.cpp
> (Although I did originally start with the function in a separate file!)
>
> Andy
>
> > -----Original Message-----
> > From: Mark Salter [ mailto:msalter@redhat.com ]
> > Sent: 17 August 2001 15:36
> > To: Andy.Simpkins@Transcomm.uk.com
> > Cc: ecos-discuss@sources.redhat.com
> > Subject: Re: [ECOS] forwarded message from Simpkins, Andy
> >
> >
> > >>>>> Simpkins, Andy writes:
> >
> > > Sorry no go...
> > > it ignores the long_call statment and gives the same error
> > in the linker...
> >
> > Do you also have the __attribute__() on any extern declarations in
> > header files? If so, then I'm all out of suggestions.
> >
> > --Mark
> >
>
--
David Airlie, Software Engineer, Parthus Technologies plc.,
Mary Rosse Centre, National Tech Park, Limerick, Ireland.
t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] forwarded message from Simpkins, Andy
2001-08-17 7:42 Simpkins, Andy
2001-08-17 7:46 ` David Airlie
@ 2001-08-17 7:46 ` Mark Salter
1 sibling, 0 replies; 18+ messages in thread
From: Mark Salter @ 2001-08-17 7:46 UTC (permalink / raw)
To: Andy.Simpkins; +Cc: ecos-discuss
>>>>> Simpkins, Andy writes:
> Nope there are no header files associated with this - to keep bad header
> files out of the equation all of the code is resident in the file main.cpp
> (Although I did originally start with the function in a separate file!)
You might try breaking it out into a seperate compilation unit.
Gcc may be ignoring the long_call attribute for calls made from
within the same compilation unit. But that is just a WAG.
--Mark
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [ECOS] forwarded message from Simpkins, Andy
@ 2001-08-17 7:42 Simpkins, Andy
2001-08-17 7:46 ` David Airlie
2001-08-17 7:46 ` Mark Salter
0 siblings, 2 replies; 18+ messages in thread
From: Simpkins, Andy @ 2001-08-17 7:42 UTC (permalink / raw)
To: Mark Salter; +Cc: ecos-discuss
Nope there are no header files associated with this - to keep bad header
files out of the equation all of the code is resident in the file main.cpp
(Although I did originally start with the function in a separate file!)
Andy
> -----Original Message-----
> From: Mark Salter [ mailto:msalter@redhat.com ]
> Sent: 17 August 2001 15:36
> To: Andy.Simpkins@Transcomm.uk.com
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
>
>
> >>>>> Simpkins, Andy writes:
>
> > Sorry no go...
> > it ignores the long_call statment and gives the same error
> in the linker...
>
> Do you also have the __attribute__() on any extern declarations in
> header files? If so, then I'm all out of suggestions.
>
> --Mark
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] forwarded message from Simpkins, Andy
2001-08-17 7:31 Simpkins, Andy
@ 2001-08-17 7:36 ` Mark Salter
0 siblings, 0 replies; 18+ messages in thread
From: Mark Salter @ 2001-08-17 7:36 UTC (permalink / raw)
To: Andy.Simpkins; +Cc: ecos-discuss
>>>>> Simpkins, Andy writes:
> Sorry no go...
> it ignores the long_call statment and gives the same error in the linker...
Do you also have the __attribute__() on any extern declarations in
header files? If so, then I'm all out of suggestions.
--Mark
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [ECOS] forwarded message from Simpkins, Andy
@ 2001-08-17 7:31 Simpkins, Andy
2001-08-17 7:36 ` Mark Salter
0 siblings, 1 reply; 18+ messages in thread
From: Simpkins, Andy @ 2001-08-17 7:31 UTC (permalink / raw)
To: Mark Salter; +Cc: ecos-discuss
Sorry no go...
it ignores the long_call statment and gives the same error in the linker...
$ arm-elf-gcc -c -DMINIMAL_IOSTREAM -DECOS -DCLED -DDEBUGBLD -I
../../../../../source/header/ -I ../../../../../source/header/additionals/
-I ./../../../../source/API/Ivory/parser -I
/i/eCOSbuilds/a161_install/include/
../../../../../source/app/ecosIvory/*.cpp -fno-rtti -fno-exceptions
../../../../../source/app/ecosIvory/main.cpp: In function `void
flash_query()':
../../../../../source/app/ecosIvory/main.cpp:63: warning: `long_call'
attribute directive ignored
$ arm-elf-gcc *.o ../../API/*/*.o -L /i/eCOSbuilds/a161_install/lib/
-Ttarget.ld -nostdlib -Xlinker -Map -Xlinker mapfile.txt
main.o: In function `main':
main.o(.text+0x1c8): relocation truncated to fit: R_ARM_PC24
flash_query(void)
collect2: ld returned 1 exit status
Andy
> -----Original Message-----
> From: Mark Salter [ mailto:msalter@redhat.com ]
> Sent: 17 August 2001 15:18
> To: Andy.Simpkins@Transcomm.uk.com
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
>
>
> >>>>> Simpkins, Andy writes:
>
> > OK that stops the compiler error but I now get
> > arm-elf-gcc *.o ../../API/*/*.o -L /i/eCOSbuilds/a161_install/lib/
> > -Ttarget.ld -nostdlib -Xlinker -Map -Xlinker mapfile.txt
> > main.o: In function `main':
> > main.o(.text+0x1cc): relocation truncated to fit: R_ARM_PC24
> > flash_query(void *)
>
> > collect2: ld returned 1 exit status
>
> > any ideas?
>
> Yup. Try:
>
> void __attribute__ ((section (".2ram.flash_query"), long_call))
> flash_query(void* data)
> {
> }
>
> --Mark
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] forwarded message from Simpkins, Andy
2001-08-17 7:05 Simpkins, Andy
@ 2001-08-17 7:18 ` Mark Salter
0 siblings, 0 replies; 18+ messages in thread
From: Mark Salter @ 2001-08-17 7:18 UTC (permalink / raw)
To: Andy.Simpkins; +Cc: ecos-discuss
>>>>> Simpkins, Andy writes:
> OK that stops the compiler error but I now get
> arm-elf-gcc *.o ../../API/*/*.o -L /i/eCOSbuilds/a161_install/lib/
> -Ttarget.ld -nostdlib -Xlinker -Map -Xlinker mapfile.txt
> main.o: In function `main':
> main.o(.text+0x1cc): relocation truncated to fit: R_ARM_PC24
> flash_query(void *)
> collect2: ld returned 1 exit status
> any ideas?
Yup. Try:
void __attribute__ ((section (".2ram.flash_query"), long_call))
flash_query(void* data)
{
}
--Mark
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [ECOS] forwarded message from Simpkins, Andy
@ 2001-08-17 7:05 Simpkins, Andy
2001-08-17 7:18 ` Mark Salter
0 siblings, 1 reply; 18+ messages in thread
From: Simpkins, Andy @ 2001-08-17 7:05 UTC (permalink / raw)
To: Mark Salter, jskov; +Cc: ecos-discuss
OK that stops the compiler error but I now get
arm-elf-gcc *.o ../../API/*/*.o -L /i/eCOSbuilds/a161_install/lib/
-Ttarget.ld -nostdlib -Xlinker -Map -Xlinker mapfile.txt
main.o: In function `main':
main.o(.text+0x1cc): relocation truncated to fit: R_ARM_PC24
flash_query(void *)
collect2: ld returned 1 exit status
any ideas?
Andy
> -----Original Message-----
> From: Mark Salter [ mailto:msalter@redhat.com ]
> Sent: 17 August 2001 14:56
> To: jskov@redhat.com
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
>
>
> >>>>> Jesper Skov writes:
>
> >> void flash_query(void* data) __attribute__ ((section
> >> (".2ram.flash_query")));
> >>
>
> > this always gives a compiler error :
>
> > parse error before `{'
>
> > when I have the following function
>
> > void flash_query(void* data) __attribute__ ((section
> (".2ram.flash_query")))
> > {
> > // do something
> > }
>
> The attribute has to come before the function name, right. This
> should work:
>
> void __attribute__ ((section (".2ram.flash_query")))
> flash_query(void* data)
> {
> // do something
> }
>
> --Mark
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] forwarded message from Simpkins, Andy
2001-08-17 6:44 Jesper Skov
@ 2001-08-17 6:55 ` Mark Salter
0 siblings, 0 replies; 18+ messages in thread
From: Mark Salter @ 2001-08-17 6:55 UTC (permalink / raw)
To: jskov; +Cc: ecos-discuss
>>>>> Jesper Skov writes:
>> void flash_query(void* data) __attribute__ ((section
>> (".2ram.flash_query")));
>>
> this always gives a compiler error :
> parse error before `{'
> when I have the following function
> void flash_query(void* data) __attribute__ ((section (".2ram.flash_query")))
> {
> // do something
> }
The attribute has to come before the function name, right. This
should work:
void __attribute__ ((section (".2ram.flash_query"))) flash_query(void* data)
{
// do something
}
--Mark
^ permalink raw reply [flat|nested] 18+ messages in thread
* [ECOS] forwarded message from Simpkins, Andy
@ 2001-08-17 6:44 Jesper Skov
2001-08-17 6:55 ` Mark Salter
0 siblings, 1 reply; 18+ messages in thread
From: Jesper Skov @ 2001-08-17 6:44 UTC (permalink / raw)
To: ecos-discuss
To : Jesper Skov <jskov at redhat dot com>
Subject : RE: [ECOS] running code from RAM / Memory Regions
From : "Simpkins, Andy" <Andy dot Simpkins at Transcomm dot uk dot com>
Date : Fri, 17 Aug 2001 14:36:52 +0100
Hi there,
Thanks for the pointers, I am afraid that I still need a little more help
though
Thanks
Andy
> -----Original Message-----
> From: Jesper Skov [ mailto:jskov@redhat.com ]
> Sent: 17 August 2001 10:58
> To: Simpkins, Andy
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] running code from RAM / Memory Regions
>
>
> >>>>> "Simpkins," == Simpkins, Andy
> <Andy.Simpkins@Transcomm.uk.com> writes:
>
> Simpkins,> Am I approaching this the write way? Are there any
> Simpkins,> pitfalls I should watch out for? Has this already been
> Simpkins,> done (obviously it has) but is the code available?
>
> Simply mark the function to be located in .2ram and it will
> automagically do the right thing:
>
> void flash_query(void* data) __attribute__ ((section
> (".2ram.flash_query")));
>
this always gives a compiler error :
parse error before `{'
when I have the following function
void flash_query(void* data) __attribute__ ((section (".2ram.flash_query")))
{
// do something
}
>
> That is, assuming you are using eCos from CVS. Otherwise you'll need
> to hack the arm.ld file so it contains a .data rule like this:
No I am not using a CVS snapshot so shall need the following...
>
> #define SECTION_data(_region_, _vma_, _lma_) \
> .data _vma_ : _lma_ \
> { __ram_data_start = ABSOLUTE (.); *(.data*) *(.data1)
> MERGE_IN_RODATA \
> _GOT1_START_ = ABSOLUTE (.); *(.got1) _GOT1_END_ = ABSOLUTE (.); \
> _GOT2_START_ = ABSOLUTE (.); *(.got2) _GOT2_END_ = ABSOLUTE (.); \
> . = ALIGN (4); \
> KEEP(*( SORT (.ecos.table.*))) ; \
> . = ALIGN (4); \
> __CTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.ctors*)))
> __CTOR_END__ = ABSOLUTE (.); \
> __DTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.dtors*)))
> __DTOR_END__ = ABSOLUTE (.); \
> *(.dynamic) *(.sdata*) *(.sbss*) \
> . = ALIGN (4); *(.2ram.*) } \
> > _region_ \
> __rom_data_start = LOADADDR (.data); \
> __ram_data_end = .; PROVIDE (__ram_data_end = .); _edata
> = .; PROVIDE (edata = .); \
> PROVIDE (__rom_data_end = LOADADDR (.data) + SIZEOF(.data));
I couldn't use your example directly because I also needed the section for
__DEVTAB__ but have been able to get this part working...
>
> Cheers,
> Jesper
>
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2001-08-20 8:47 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-17 9:24 [ECOS] forwarded message from Simpkins, Andy Simpkins, Andy
2001-08-17 9:31 ` Jonathan Larmour
2001-08-17 10:13 ` Mark Salter
-- strict thread matches above, loose matches on Subject: below --
2001-08-20 8:47 Simpkins, Andy
2001-08-20 1:12 Simpkins, Andy
2001-08-20 6:25 ` Jonathan Larmour
2001-08-17 9:33 Simpkins, Andy
2001-08-17 8:24 Simpkins, Andy
2001-08-17 9:10 ` Jonathan Larmour
2001-08-17 7:42 Simpkins, Andy
2001-08-17 7:46 ` David Airlie
2001-08-17 7:46 ` Mark Salter
2001-08-17 7:31 Simpkins, Andy
2001-08-17 7:36 ` Mark Salter
2001-08-17 7:05 Simpkins, Andy
2001-08-17 7:18 ` Mark Salter
2001-08-17 6:44 Jesper Skov
2001-08-17 6:55 ` Mark Salter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).