> The __aeabi_unwind_cpp_pr* personality routines are *not* libunwind
>functions either, they are also functions from libgcc_eh. Anything
>related to those functions should not use the term "libunwind",
>whether in configure option names, or patch submissions, since it is
>not libunwind. Link
-Joseph Myers wrote: -
>On Wed, 13 Jun 2012, Fredrik Hederstierna wrote:
> >You need to provide a self-contained explanation of what the problem
> >is that your patch is fixing and why you chose that approach to
> >fixing it - with reference to the ARM EABI documentes (RTABI etc.)
> >f
On Wed, 13 Jun 2012, Fredrik Hederstierna wrote:
> >You need to provide a self-contained explanation of what the problem
> >is that your patch is fixing and why you chose that approach to
> >fixing it - with reference to the ARM EABI documentes (RTABI etc.)
> >for why your approach is valid acc
On Wed, 13 Jun 2012 09:35:42 +0200
Fredrik Hederstierna wrote:
> This is the link to the original patch.
> It contains some background information and more links.
>
> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00720.html
>
> The patch is now updated and improved by Larry Doolittle.
> /Fredrik
This is the link to the original patch.
It contains some background information and more links.
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00720.html
The patch is now updated and improved by Larry Doolittle.
/Fredrik
-Joseph Myers wrote: -
>You need to provide a self-contained explanation of what the problem
>is that your patch is fixing and why you chose that approach to
>fixing it - with reference to the ARM EABI documentes (RTABI etc.)
>for why your approach is valid according to the ARM EABI.
On 06/12/2012 04:37 PM, Joseph S. Myers wrote:
You need to provide a self-contained explanation of what the problem is
that your patch is fixing and why you chose that approach to fixing it -
with reference to the ARM EABI documentes (RTABI etc.) for why your
approach is valid according to the AR
You need to provide a self-contained explanation of what the problem is
that your patch is fixing and why you chose that approach to fixing it -
with reference to the ARM EABI documentes (RTABI etc.) for why your
approach is valid according to the ARM EABI.
libunwind is a library separate from
rik
-Larry Doolittle wrote: -
To: gcc-patches@gcc.gnu.org
From: Larry Doolittle
Date: 06/03/2012 06:35PM
Cc: Fredrik Hederstierna
Subject: [PATCH] Option to build bare-metal ARM cross-compiler for
arm-none-eabi target without libunwind
This is an update to Fredrik Hederstierna's ma
This is an update to Fredrik Hederstierna's mail and patch from
12 Apr 2012. I think he missed one place where -fexceptions needs
to be changed to -fno-exceptions.
With the attached patch, two of us (a friend and I, one on Linux and
one on Mac) can build Rockbox with gcc-4.7.0. I'll admit I have
Hello,
I think it is good to disable the exceptions for the division by zero. Maybe
this should be made target specific and not based on a configure option. For
example in "libgcc/config.host":
arm*-*-linux*)
[...]
tmake_file="${tmake_file} arm/t-div-by-zero-exc"
[..
We've been using a bare-metal 'arm-elf' cross-compiler toolchain over the years
since GCC 2.95.x/GCC3/GCC4, and it has worked fine.
Now it seems though like the 'arm-elf' target seems obsolete, and we are trying
to switch to 'arm-none-eabi'.
Though we use no standard-libs at all, we are really h
12 matches
Mail list logo
