Some notes on using GCC 4.4.1 (eh_frame)

[Michael Fischer]

Hello list,

I do not know if this is a general 4.4.x problem, but if you
using YAGARTO based on GCC 4.4.1 and if you get an error like:

error: no memory region specified for loadable section `.eh_frame'

you must add an eh_frame in your linker script too.

In case of the at91sam7se512_ram.ld file, place the following
part after the .text section:

   . = ALIGN(4);
   .eh_frame :
   {
     KEEP (*(.eh_frame))
   } > ram


Best regards,

Michael
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[uprinz]

Hmmm...

I installed the latest version from your hompage and got stuck at some
other points too:

Building NutO/S fails as the new version likes to have unsetenv() return
an int. I fixed that in nut/crt/setenv.c

The question ist, how can I detect the GCC version in the sources to
compile the right unsetenv() version?

Now I compiled my application and it breaks too:

c:/programme/yagarto/bin/../lib/gcc/arm-elf/4.4.1/../../../../arm-elf/lib\libc.a
(lib_a-mallocr.o): In function `malloc_extend_top':
C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\stdlib/../../../../../
newlib-1.17.0/newlib/libc/stdlib/mallocr.c:2160: undefined reference to
`_sbrk_r
'
C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\stdlib/../../../../../
newlib-1.17.0/newlib/libc/stdlib/mallocr.c:2197: undefined reference to
`_sbrk_r
'
c:/programme/yagarto/bin/../lib/gcc/arm-elf/4.4.1/../../../../arm-elf/lib\libc.a
(lib_a-freer.o): In function `_malloc_trim_r':
C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\stdlib/../../../../../
newlib-1.17.0/newlib/libc/stdlib/mallocr.c:3326: undefined reference to
`_sbrk_r
'
C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\stdlib/../../../../../
newlib-1.17.0/newlib/libc/stdlib/mallocr.c:3335: undefined reference to
`_sbrk_r
'
C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\stdlib/../../../../../
newlib-1.17.0/newlib/libc/stdlib/mallocr.c:3340: undefined reference to
`_sbrk_r
'
collect2: ld returned 1 exit status
make: *** [sam7x_ek_mineguard.elf] Error 1

So here I have two questions...
First, I can only find  _sbrk() functions... So here again the question
how to map them to the newlib the best way, without leaving users with
older yagarto versions in the rain?

Second, I do not have any path on my C: drive like that one:
C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\stdlib/../../.

Could it be, that there is something broken with this yagarto version?
A quich arm-elf-gcc --version showes:
arm-elf-gcc (GCC) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Thanks in advance and best regards
Ulrich

Michael Fischer schrieb:

> Hello list,
>
> I do not know if this is a general 4.4.x problem, but if you
> using YAGARTO based on GCC 4.4.1 and if you get an error like:
>
> error: no memory region specified for loadable section `.eh_frame'
>
> you must add an eh_frame in your linker script too.
>
> In case of the at91sam7se512_ram.ld file, place the following
> part after the .text section:
>
>    . = ALIGN(4);
>    .eh_frame :
>    {
>      KEEP (*(.eh_frame))
>    } > ram
>
>
> Best regards,
>
> Michael
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Hi Ulrich,

Ulrich Prinz wrote:

> Building NutO/S fails as the new version likes to have unsetenv() return
> an int. I fixed that in nut/crt/setenv.c
>
> The question ist, how can I detect the GCC version in the sources to
> compile the right unsetenv() version?

Ole added a related configuration item.
http://lists.egnite.de/pipermail/en-nut-discussion/2009-February/010366.html

Do not miss the replies to
http://sourceware.org/ml/newlib/2009/msg00144.html
I thought that newlib was done for embedded systems in general, but as
it turned out it is Linux only. :-(


> c:/programme/yagarto/bin/../lib/gcc/arm-elf/4.4.1/../../../../arm-elf/lib\libc.a
> (lib_a-mallocr.o): In function `malloc_extend_top':
> C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\stdlib/../../../../../
> newlib-1.17.0/newlib/libc/stdlib/mallocr.c:2160: undefined reference to
> `_sbrk_r

That looks like your app is referencing a function, which is not
available in Nut/OS and the linker uses the newlib function instead. You
can try to locate this problem in the map file, but sometimes this is
not easy.

Michael will hopefully be able to help with the remaining questions.
Before releasing this version, he offered it to me for testing. But I
failed to do this in time. Hope we can solve this without the need for
Michael to create a new packet. Otherwise I feel guilty.

Harald





_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[uprinz]

Ok, I read all those discussions about newlib and understand why these
linking problems show up.

 > Building NutO/S fails as the new version likes to have unsetenv() return
 > an int. I fixed that in nut/crt/setenv.c
 >
 > The question ist, how can I detect the GCC version in the sources to
 > compile the right unsetenv() version?
 >
This I fixed by configuring NutO/S to use Posix compatible unsetenv()

The rest is the previously discussed newlib problem wich obviously
nobody solved till today.

Unfortuantely I need floating point and I need it for an actual project.
I had to reinstall my system and I only find a 2006 version of yagarto.
I think I used a 2008 version before that worked quit fine. To bad that
there is no older version on sourceforge. So today I could'nt do
anything, I have to get to work to fetch the older version from the server.

I think it is not so optimal to update the compiler with breaking
compatibility and leaving the developers using it alone.
Even the comments from the wiki with arm-elf-ar -d ... doesn't work.

The systemcalls.c from yagarto.de may be a neat idea, but the function
headers don't match...

Any other idea?

Best Regards,
Ulrich

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Ulrich Prinz wrote:

> I think it is not so optimal to update the compiler with breaking
> compatibility and leaving the developers using it alone.
> Even the comments from the wiki with arm-elf-ar -d ... doesn't work.

Bad timing. Michael moved to Sourceforge in 2009 and egnite recently
moved its outdated mirror yagarto.org to a new machine, taking over the
current status of yagarto.de.

It is necessary to have previous versions available. For now I'm moving
my local backup to
http://www.ethernut.de/arc/
Unfortunately the original file dates are gone.


> The systemcalls.c from yagarto.de may be a neat idea, but the function
> headers don't match...

I must admit, that I didn't fully understand the topic. AFAIK, syscalls
had been always part of YAGARTO's newlib distribution. They often
appeared in linker errors as soon as standard C calls were referenced,
which require system functions (alloc, print etc.) and which were not
available in Nut/OS libs. E.g. using calloc or strdup in older Nut/OS
versions, which didn't support them.

I'll give it a try,

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[uprinz]

On Mon, 07 Sep 2009 10:00:58 +0200, Harald Kipp <harald.kipp@...>
wrote:

> Ulrich Prinz wrote:
>  
>> I think it is not so optimal to update the compiler with breaking  
>> compatibility and leaving the developers using it alone.
>> Even the comments from the wiki with arm-elf-ar -d ... doesn't work.
>  
> Bad timing. Michael moved to Sourceforge in 2009 and egnite recently
> moved its outdated mirror yagarto.org to a new machine, taking over the
> current status of yagarto.de.
>  
> It is necessary to have previous versions available. For now I'm moving
> my local backup to
> http://www.ethernut.de/arc/ 
> Unfortunately the original file dates are gone.
>  

I normally save my toolchains together with my projects. Unfortunately I
didn't do that this time. May be caus it's a long time ago when I was
thinking about using NutO/S or not. But I found a version including GCC
4.1.1 and that one workes flawlessly.

>  
>> The systemcalls.c from yagarto.de may be a neat idea, but the function  
>> headers don't match...
>  
> I must admit, that I didn't fully understand the topic. AFAIK, syscalls
> had been always part of YAGARTO's newlib distribution. They often
> appeared in linker errors as soon as standard C calls were referenced,
> which require system functions (alloc, print etc.) and which were not
> available in Nut/OS libs. E.g. using calloc or strdup in older Nut/OS
> versions, which didn't support them.
>  
> I'll give it a try,
>  

I can try to reproduce the differences between 4.1.1 and 4.4.1 compiler
running through NutO/S 4.9.3.0. But this will take a few days.
 
What I found out at work was, that I accidentially used fileno() instead of
_fileno() what gave me a lot of lib related errors. ( Missing _strtok())
But there where no *_r (reentrant) errors. I didn't made such a mistake on
my try yesterday, as I compiled a software that ran without problems before
I reinstalled Windows on my Workstation. ( I am going modern, I installed
XP :) )
So I simply tried the new installed compiler to check if it's working.
 
I expected openocd 0.2.0 to make trouble and yagarto to run fine. But
according to Murphy's law openocd started out of the box so yagarto had to
fail :)
 
I scan the code for possible links to the wrong libs. But I don't know all
the functions. So it may last a while. May be that explains, why the
Ethernet Stack crashes if a button is pressed :)
 
Best regards
Ulrich
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Ulrich Prinz wrote:

> So I simply tried the new installed compiler to check if it's working.

After adding Michael's fix to the linker script the compiler did fine on
all targets. This fix was a drag, because it includes many linker
scripts, written in different ways.

So I checked, what could be done here in the future. See my next post
about CMake.

Harald

PS. I didn't test the resulting binaries yet.

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Michael Fischer]

Hello List,

if someone need older versions from YAGARTO, drop me a mail, and
I will enabled it again on sourceforge.

Best regards,

Michael
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion