[ECOS] Enable thumb interworking?

[ECOS] Enable thumb interworking?

[Lewin A.R.W. Edwards]

Since it's not possible to build the eCos kernel with thumb enabled, I have 
been attempting to build my application with -mthumb and -mthumb-interwork, 
and the eCos kernel with just -mthumb-interwork.

However, when I link my application with, arm-elf-ld tells me that none of 
the eCos kernel modules have interworking enabled, and obviously the binary 
is useless because of this.

Is there a way to get this working? (is it -mthumb-interwork or 
-fthumb-interwork? Neither appears to work, anyway)

Secondly, why is the ecos/install/lib/target.ld file always generated 
incorrectly by ecosconfig? The spacing is all screwed; every word has a 
carriage return after it. I have to copy the linker script from my Windows 
machine in order to link at all.
=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] Enable thumb interworking?

[Bart Veer]

>>>>> "Lewin" == Lewin A R W Edwards <larwe@larwe.com> writes:

    Lewin> Secondly, why is the ecos/install/lib/target.ld file always
    Lewin> generated incorrectly by ecosconfig? The spacing is all
    Lewin> screwed; every word has a carriage return after it. I have
    Lewin> to copy the linker script from my Windows machine in order
    Lewin> to link at all.

target.ld is not build by ecosconfig, it is built by a custom build
step defined in the CDL for the architectural HAL package. For an ARM
processor that means the following:

        <PREFIX>/lib/target.ld: <PACKAGE>/src/arm.ld
        $(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH) $(CFLAGS) -o $@ $<
        @echo $@ ": \\" > $(notdir $@).deps
        @tail +2 target.tmp >> $(notdir $@).deps
        @echo >> $(notdir $@).deps
        @rm target.tmp

The first command is the important one. Essentially it passes the
arm.ld file from the src subdirectory of the ARM architectural HAL
package through the C preprocessor. It ends up #include'ing a
file provided by the platform HAL which supplies information such as
what memory is actually available.

If you are seeing spurious carriage returns then either these are
generated by the C preprocessor, or some of the files being #include'd
contain spurious carriage returns e.g. because they were just copied
directly from a Windows box. I have never seen the actual behaviour
you describe, so you'll have to investigate further. Problems with the
C preprocessor should be reported to the appropriate gcc mailing list.

Bart

Re: [ECOS] Enable thumb interworking?

[Lewin A.R.W. Edwards]

Hi again Bart,

>    Lewin> Secondly, why is the ecos/install/lib/target.ld file always
>     Lewin> generated incorrectly by ecosconfig? The spacing is all
>     Lewin> screwed; every word has a carriage return after it. I have
>
>generated by the C preprocessor, or some of the files being #include'd
>contain spurious carriage returns e.g. because they were just copied
>directly from a Windows box. I have never seen the actual behaviour
>you describe, so you'll have to investigate further. Problems with the

I could understand that... I have redownloaded _all_ the components using 
Linux (so every text file I have, particularly thinking here of CVS stuff, 
should now be UNIX-EOL-convention), I will try it out later this afternoon.

It is odd that it's only this one file affected. Is there no other 
intermediate file in eCos that's generated with the same process?

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] Enable thumb interworking?

[Bart Veer]

>>>>> "Lewin" == Lewin A R W Edwards <larwe@larwe.com> writes:

    Lewin> Hi again Bart,
    Lewin> Secondly, why is the ecos/install/lib/target.ld file always
    Lewin> generated incorrectly by ecosconfig? The spacing is all
    Lewin> screwed; every word has a carriage return after it. I have

    >> generated by the C preprocessor, or some of the files being
    >> #include'd contain spurious carriage returns e.g. because they
    >> were just copied directly from a Windows box. I have never seen
    >> the actual behaviour you describe, so you'll have to
    >> investigate further. Problems with the

    Lewin> I could understand that... I have redownloaded _all_ the
    Lewin> components using Linux (so every text file I have,
    Lewin> particularly thinking here of CVS stuff, should now be
    Lewin> UNIX-EOL-convention), I will try it out later this
    Lewin> afternoon.

    Lewin> It is odd that it's only this one file affected. Is there
    Lewin> no other intermediate file in eCos that's generated with
    Lewin> the same process?

A quick find/fgrep combo suggests that most occurrences of $(CC) -E
are either in architectural or platform HALs, presumably to generate
the linker script. One other candidate is in the current memory
allocator services package CYGPKG_MEMALLOC (anoncvs, not 1.3.1) where
I see the following:

        make -priority 50 {
            heapgeninc.tcl : <PACKAGE>/src/heapgen.cpp
            $(CC) $(CFLAGS) $(INCLUDE_PATH) -Wp,-MD,heapgen.tmp -E $< > $@
            @echo $@ ':' $< '\' > $(notdir $@).deps
            @tail +2 heapgen.tmp >> $(notdir $@).deps
            @echo >> $(notdir $@).deps
            @rm heapgen.tmp
        }

So if your configuration is based on anoncvs and uses malloc, you
might want to check what happens here. 

Bart