[PATCH] config.gcc (x86_64-*-rtems*): Add rtems.h to tm_file
Hi!
All the gcc targets for RTEMS include gcc/config/rtems.h in tm_file to add
specific linker options using LIB_SPEC.
This patch simply intends to add the same to the x86_64 target.
There are no tests in this patch because I don't see any tests for any of the
other RTEMS targets - let me know if you'd be interested in a patch for that,
and I can look into adding general tests for all the RTEMS targets or just
specific ones that _must_ support these switches - Joel and Sebastian may be
able to shed light on which it should be, if any.
P.S. - I've also added this patch to rtems-source-builder and built gcc to
verify that it works (in that the new switches do not throw "unrecognized
command line option" errors anymore, at least). Let me know if you'd like a
patch to test with rtems-source-builder, if that makes it easier for you to
verify.
Thanks!
gcc/ChangeLog:
2018-04-07 Amaan Cheval
* config.gcc (x86_64-*-rtems*): Add rtems.h to tm_file for
custom LIB_SPEC setup.
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 259188)
+++ gcc/config.gcc (working copy)
@@ -1496,7 +1496,7 @@ x86_64-*-elf*)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h newlib-stdint.h
i386/i386elf.h i386/x86-64.h"
;;
x86_64-*-rtems*)
- tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself.h"
+ tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself.h rtems.h"
;;
i[34567]86-*-rdos*)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
newlib-stdint.h i386/i386elf.h i386/rdos.h"
Re: [PATCH] config.gcc (x86_64-*-rtems*): Add rtems.h to tm_file
On Sat, Apr 7, 2018 at 1:49 AM Joel Sherrill wrote:
> Thanks for submitting the patch. This patch is OK to merge to the
> master and all open branches that have this target.
> A corresponding patch for the RTEMS Source Builder is necessary
> because a gcc release with this patch won't be available for a while.
Yep, I figured it'd be the same style as we have for some of the other
patches that refer directly to the gcc.git commit:
https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-gcc-7.2.0-newlib-2.5.0.20170922-1.cfg#n24
1. Is that right? Or would we rather commit the patch into
rtems-source-builder and use "--rsb-file"? I imagine it doesn't really make
a difference, so I'll just go with the former if you don't have a
preference.
2. Would only the "rtems-gcc-7.3.0-newlib-3.0.0.cfg" file need the patch
(since it seems to be what the rtems-source-builder uses for the
"5/rtems-x86_64" buildset[1][2]), or would there be more? (I don't see the
need to support older versions since the port won't exist for a while, so
the tools don't need to be updated backwards either.)
[1]
https://git.rtems.org/rtems-source-builder/tree/rtems/config/5/rtems-x86_64.bset#n4
[2]
https://git.rtems.org/rtems-source-builder/tree/rtems/config/5/rtems-default.bset#n14
> I am starting a build with this now. If Sebastian pushes it before me,
> that's OK.
> --joel
> On Fri, Apr 6, 2018 at 3:05 PM, Amaan Cheval
wrote:
>> Hi!
>> All the gcc targets for RTEMS include gcc/config/rtems.h in tm_file to
add
>> specific linker options using LIB_SPEC.
>> This patch simply intends to add the same to the x86_64 target.
>> There are no tests in this patch because I don't see any tests for any
of the
>> other RTEMS targets - let me know if you'd be interested in a patch for
that,
>> and I can look into adding general tests for all the RTEMS targets or
just
>> specific ones that _must_ support these switches - Joel and Sebastian
may be
>> able to shed light on which it should be, if any.
>> P.S. - I've also added this patch to rtems-source-builder and built gcc
to
>> verify that it works (in that the new switches do not throw "unrecognized
>> command line option" errors anymore, at least). Let me know if you'd
like a
>> patch to test with rtems-source-builder, if that makes it easier for you
to
>> verify.
>> Thanks!
>> gcc/ChangeLog:
>> 2018-04-07 Amaan Cheval
>> * config.gcc (x86_64-*-rtems*): Add rtems.h to tm_file for
>> custom LIB_SPEC setup.
>> Index: gcc/config.gcc
>> ===
>> --- gcc/config.gcc (revision 259188)
>> +++ gcc/config.gcc (working copy)
>> @@ -1496,7 +1496,7 @@ x86_64-*-elf*)
>> tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
newlib-stdint.h i386/i386elf.h i386/x86-64.h"
>> ;;
>> x86_64-*-rtems*)
>> - tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself.h"
>> + tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself.h rtems.h"
>> ;;
>> i[34567]86-*-rdos*)
>> tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
newlib-stdint.h i386/i386elf.h i386/rdos.h"
[PATCH] Build i386's crti.o and crtn.o for x86_64-*-rtems*
Hi!
The x86_64 RTEMS target doesn't currently have gcc build crti.o and crtn.o. This
surfaces as undefined references to "_fini", which RTEMS references in its
kernel:
https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/newlibc_exit.c#n39
Most other architectures deal with this by adding crti.o to the startfile in
bsp_specs:
https://git.rtems.org/rtems/tree/bsps/i386/pc386/start/bsp_specs#n6
This patch uses GCC's i386's crti.S and crtn.S (since x86_64-*-* targets use
"cpu_type=i386") as the source for the object files:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/i386/crti.S;h=c25e8f9e3ab45e935f6287d5ed3a8437a289e059;hb=HEAD
The patch is as follows:
libgcc/ChangeLog:
2018-05-01 Amaan Cheval
* config.host: Build i386's crti.o and crtn.o for x86_64-*-rtems*
Index: libgcc/config.host
===
--- libgcc/config.host (revision 259789)
+++ libgcc/config.host (working copy)
@@ -611,6 +611,11 @@ i[34567]86-*-elf*)
;;
x86_64-*-elf* | x86_64-*-rtems*)
tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic t-libgcc-pic"
+ case ${host} in
+ x86_64-*-rtems*)
+ extra_parts="$extra_parts crti.o crtn.o"
+ ;;
+ esac
;;
x86_64-*-fuchsia*)
tmake_file="$tmake_file t-libgcc-pic"
Re: [PATCH] Build i386's crti.o and crtn.o for x86_64-*-rtems*
Hey!
Just thought I'd bump this patch and see if anyone had a chance to look at
it! Let me know if you have any questions or would like anything to be
different (for eg. to split "x86_64-*-elf*" and "x86_64-*-rtems*" into
their own case statements, instead of what I have here.
On Tue, May 1, 2018 at 3:24 PM Amaan Cheval wrote:
> Hi!
> The x86_64 RTEMS target doesn't currently have gcc build crti.o and
crtn.o. This
> surfaces as undefined references to "_fini", which RTEMS references in its
> kernel:
> https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/newlibc_exit.c#n39
> Most other architectures deal with this by adding crti.o to the startfile
in
> bsp_specs:
> https://git.rtems.org/rtems/tree/bsps/i386/pc386/start/bsp_specs#n6
> This patch uses GCC's i386's crti.S and crtn.S (since x86_64-*-* targets
use
> "cpu_type=i386") as the source for the object files:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/i386/crti.S;h=c25e8f9e3ab45e935f6287d5ed3a8437a289e059;hb=HEAD
> The patch is as follows:
> libgcc/ChangeLog:
> 2018-05-01 Amaan Cheval
> * config.host: Build i386's crti.o and crtn.o for x86_64-*-rtems*
> Index: libgcc/config.host
> ===
> --- libgcc/config.host (revision 259789)
> +++ libgcc/config.host (working copy)
> @@ -611,6 +611,11 @@ i[34567]86-*-elf*)
> ;;
> x86_64-*-elf* | x86_64-*-rtems*)
> tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic
t-libgcc-pic"
> + case ${host} in
> + x86_64-*-rtems*)
> + extra_parts="$extra_parts crti.o crtn.o"
> + ;;
> + esac
> ;;
> x86_64-*-fuchsia*)
> tmake_file="$tmake_file t-libgcc-pic"
