Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

2018-08-10 Thread Amaan Cheval
Haha, don't worry about it. It's really a non-blocker we can
absolutely handle after GSoC just as well. I just wanted to confirm in
case I'd missed something!

On Fri, Aug 10, 2018 at 6:55 PM, Joel Sherrill  wrote:
> I am sorry. I will have to dig this up and commit it.
>
> I will try to do this before I leave about lunch.
>
> Looks like we both have work to do before the end of GSoC. :)
>
> --joel
>
> On Fri, Aug 10, 2018 at 6:11 AM, Amaan Cheval 
> wrote:
>>
>> Hey Joel!
>>
>> I'm not sure if this ever made it upstream - if it did, could you dig
>> the commit up?
>>
>> I'll leave the x86_64's bsp_specs empty and make the RSB backporting
>> patches accordingly. If not, no rush, we should just add a ticket or
>> something so as to not lose track of it entirely after GSoC ends.
>>
>> On Mon, Jul 9, 2018 at 10:30 AM, Amaan Cheval 
>> wrote:
>> > To make my previous email clearer, here's what I meant with the
>> > "minimal" GCC patch required (attached).
>> >
>> > To manually test, you can place gcc-STARTFILE_SPEC.patch in
>> > $RSB/rtems/patches/ and then "git apply rsb-startfile.diff" to the RSB
>> > repo. Then build GCC and confirm that "x86_64-rtems5-gcc -dumpspecs"
>> > includes crti and crtbegin in the startfile susbtitution.
>> >
>> > Let me know if we aim to have this GCC work done before merging the
>> > x86_64 BSP (see
>> > https://lists.rtems.org/pipermail/devel/2018-July/022388.html) so I
>> > can leave bsp_specs in or clear it out accordingly?
>> >
>> > For now, I'm going to leave it in.
>> >
>> > On Fri, Jul 6, 2018 at 10:46 AM, Amaan Cheval 
>> > wrote:
>> >> Hey, Joel!
>> >>
>> >> The x86_64 BSP currently uses an empty bsp_specs file contingent on
>> >> (at least the x86-64 parts of) this email thread's patch making it
>> >> upstream to GCC, and making their way into the RSB.
>> >>
>> >> 2 options:
>> >> - 1. Make the upstream GCC commit (at least the parts adding
>> >> rtemself64.h, editing config.gcc, and "#if 0"ing out
>> >> gcc/config/rtems.h)
>> >> - 2. Use a bsp_specs in the new BSP for the merge now, and empty it out
>> >> later
>> >>
>> >> I can test and send you an x86_64 specific patch for GCC if you'd
>> >> like. Or if you prefer to have all the work together, we can go with
>> >> #2.
>> >>
>> >> Let me know!
>> >>
>> >> On Sat, May 19, 2018 at 3:17 AM, Joel Sherrill  wrote:
>> >>> Thanks. I will try to deal with this Monday.
>> >>>
>> >>> My specs patches are not ready to push to gcc so I need to focus on
>> >>> just the parts to make x86_64 right.
>> >>>
>> >>> On Fri, May 18, 2018 at 3:41 PM, Amaan Cheval 
>> >>> wrote:
>> 
>>  To be clear, I applied this patch (with my fixes) on the 7.3 release
>>  through the RSB to test, not on GCC's master branch.
>> 
>>  > to add i386/rtemself64.h
>> 
>>  What you sent in this email thread adds rtemself64.h already. Do you
>>  mean you'd like to split the commits up or something?
>> 
>>  The only changes I made on top of yours were:
>> 
>>  - Readd "rtems.h" to config.gcc
>>  - Fix comments
>> 
>>  I've attached the patch file I used within the RSB here (sorry if you
>>  meant a patch of _just_ the fixes I made on top of yours, this is
>>  just
>>  the cumulative diff I used to patch GCC 7.3 to test).
>> 
>>  Regards,
>> 
>>  On Fri, May 18, 2018 at 7:00 PM, Joel Sherrill 
>>  wrote:
>>  >
>>  >
>>  >
>>  > On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval
>>  > 
>>  > wrote:
>>  >>
>>  >> I just compiled my local fixed copy (adding rtems.h back in) and
>>  >> there's good news! With the patch, the x86_64 compile stub works
>>  >> with
>>  >> a blank bsp_specs file!
>>  >
>>  >
>>  > Awesome!
>>  >
>>  > Can you send me your changes as a patch? I am thinking I need to
>>  > make
>>  > sure we agree on what the gcc master for x86_64-rtems looks like.
>>  >
>>  > Apparently I owe committing a patch to add i386/rtemself64.h since
>>  > it is
>>  > missing on the master. And the comment is wrong.  What else?
>>  >
>>  >> On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval
>>  >> 
>>  >> wrote:
>>  >> > Hey!
>>  >> >
>>  >> > Thanks so much for sharing this, it's quite useful to put your
>>  >> > earlier
>>  >> > email[1] about minimzing the bsp_specs in context.
>>  >> >
>>  >> > From looking ahead a bit without testing (still compiling), the
>>  >> > patch
>>  >> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it
>>  >> > defines
>>  >> > __TMC_END__ which crtbegin.o has left undefined for eg.) and
>>  >> > possibly
>>  >> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs
>>  >> > entirely
>>  >> > (see here[2]).
>>  >>
>>  >> Just noticed that ENDFILE_SPEC already includes crtend in
>>  >> i386elf.h,
>>  >> so there's no need for this change.
>>  >>
>> 

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

2018-08-10 Thread Joel Sherrill
I am sorry. I will have to dig this up and commit it.

I will try to do this before I leave about lunch.

Looks like we both have work to do before the end of GSoC. :)

--joel

On Fri, Aug 10, 2018 at 6:11 AM, Amaan Cheval 
wrote:

> Hey Joel!
>
> I'm not sure if this ever made it upstream - if it did, could you dig
> the commit up?
>
> I'll leave the x86_64's bsp_specs empty and make the RSB backporting
> patches accordingly. If not, no rush, we should just add a ticket or
> something so as to not lose track of it entirely after GSoC ends.
>
> On Mon, Jul 9, 2018 at 10:30 AM, Amaan Cheval 
> wrote:
> > To make my previous email clearer, here's what I meant with the
> > "minimal" GCC patch required (attached).
> >
> > To manually test, you can place gcc-STARTFILE_SPEC.patch in
> > $RSB/rtems/patches/ and then "git apply rsb-startfile.diff" to the RSB
> > repo. Then build GCC and confirm that "x86_64-rtems5-gcc -dumpspecs"
> > includes crti and crtbegin in the startfile susbtitution.
> >
> > Let me know if we aim to have this GCC work done before merging the
> > x86_64 BSP (see
> > https://lists.rtems.org/pipermail/devel/2018-July/022388.html) so I
> > can leave bsp_specs in or clear it out accordingly?
> >
> > For now, I'm going to leave it in.
> >
> > On Fri, Jul 6, 2018 at 10:46 AM, Amaan Cheval 
> wrote:
> >> Hey, Joel!
> >>
> >> The x86_64 BSP currently uses an empty bsp_specs file contingent on
> >> (at least the x86-64 parts of) this email thread's patch making it
> >> upstream to GCC, and making their way into the RSB.
> >>
> >> 2 options:
> >> - 1. Make the upstream GCC commit (at least the parts adding
> >> rtemself64.h, editing config.gcc, and "#if 0"ing out
> >> gcc/config/rtems.h)
> >> - 2. Use a bsp_specs in the new BSP for the merge now, and empty it out
> later
> >>
> >> I can test and send you an x86_64 specific patch for GCC if you'd
> >> like. Or if you prefer to have all the work together, we can go with
> >> #2.
> >>
> >> Let me know!
> >>
> >> On Sat, May 19, 2018 at 3:17 AM, Joel Sherrill  wrote:
> >>> Thanks. I will try to deal with this Monday.
> >>>
> >>> My specs patches are not ready to push to gcc so I need to focus on
> >>> just the parts to make x86_64 right.
> >>>
> >>> On Fri, May 18, 2018 at 3:41 PM, Amaan Cheval 
> >>> wrote:
> 
>  To be clear, I applied this patch (with my fixes) on the 7.3 release
>  through the RSB to test, not on GCC's master branch.
> 
>  > to add i386/rtemself64.h
> 
>  What you sent in this email thread adds rtemself64.h already. Do you
>  mean you'd like to split the commits up or something?
> 
>  The only changes I made on top of yours were:
> 
>  - Readd "rtems.h" to config.gcc
>  - Fix comments
> 
>  I've attached the patch file I used within the RSB here (sorry if you
>  meant a patch of _just_ the fixes I made on top of yours, this is just
>  the cumulative diff I used to patch GCC 7.3 to test).
> 
>  Regards,
> 
>  On Fri, May 18, 2018 at 7:00 PM, Joel Sherrill 
> wrote:
>  >
>  >
>  >
>  > On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval <
> amaan.che...@gmail.com>
>  > wrote:
>  >>
>  >> I just compiled my local fixed copy (adding rtems.h back in) and
>  >> there's good news! With the patch, the x86_64 compile stub works
> with
>  >> a blank bsp_specs file!
>  >
>  >
>  > Awesome!
>  >
>  > Can you send me your changes as a patch? I am thinking I need to
> make
>  > sure we agree on what the gcc master for x86_64-rtems looks like.
>  >
>  > Apparently I owe committing a patch to add i386/rtemself64.h since
> it is
>  > missing on the master. And the comment is wrong.  What else?
>  >
>  >> On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval <
> amaan.che...@gmail.com>
>  >> wrote:
>  >> > Hey!
>  >> >
>  >> > Thanks so much for sharing this, it's quite useful to put your
>  >> > earlier
>  >> > email[1] about minimzing the bsp_specs in context.
>  >> >
>  >> > From looking ahead a bit without testing (still compiling), the
> patch
>  >> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it
>  >> > defines
>  >> > __TMC_END__ which crtbegin.o has left undefined for eg.) and
> possibly
>  >> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs
> entirely
>  >> > (see here[2]).
>  >>
>  >> Just noticed that ENDFILE_SPEC already includes crtend in
> i386elf.h,
>  >> so there's no need for this change.
>  >>
>  >> >
>  >> > I've also left some comments inline below.
>  >> >
>  >> > +1 on upstreaming this into GCC (making sure it also backports
> to 7.3
>  >> > for simplicity, so we don't need to write a 7.3-specific patch
> for
>  >> > the
>  >> > RSB as well) with a few additons (at least for the x86_64
> target, to
>  >> > try to have an empty bsp_specs to begin with).
> 

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

2018-08-10 Thread Amaan Cheval
Hey Joel!

I'm not sure if this ever made it upstream - if it did, could you dig
the commit up?

I'll leave the x86_64's bsp_specs empty and make the RSB backporting
patches accordingly. If not, no rush, we should just add a ticket or
something so as to not lose track of it entirely after GSoC ends.

On Mon, Jul 9, 2018 at 10:30 AM, Amaan Cheval  wrote:
> To make my previous email clearer, here's what I meant with the
> "minimal" GCC patch required (attached).
>
> To manually test, you can place gcc-STARTFILE_SPEC.patch in
> $RSB/rtems/patches/ and then "git apply rsb-startfile.diff" to the RSB
> repo. Then build GCC and confirm that "x86_64-rtems5-gcc -dumpspecs"
> includes crti and crtbegin in the startfile susbtitution.
>
> Let me know if we aim to have this GCC work done before merging the
> x86_64 BSP (see
> https://lists.rtems.org/pipermail/devel/2018-July/022388.html) so I
> can leave bsp_specs in or clear it out accordingly?
>
> For now, I'm going to leave it in.
>
> On Fri, Jul 6, 2018 at 10:46 AM, Amaan Cheval  wrote:
>> Hey, Joel!
>>
>> The x86_64 BSP currently uses an empty bsp_specs file contingent on
>> (at least the x86-64 parts of) this email thread's patch making it
>> upstream to GCC, and making their way into the RSB.
>>
>> 2 options:
>> - 1. Make the upstream GCC commit (at least the parts adding
>> rtemself64.h, editing config.gcc, and "#if 0"ing out
>> gcc/config/rtems.h)
>> - 2. Use a bsp_specs in the new BSP for the merge now, and empty it out later
>>
>> I can test and send you an x86_64 specific patch for GCC if you'd
>> like. Or if you prefer to have all the work together, we can go with
>> #2.
>>
>> Let me know!
>>
>> On Sat, May 19, 2018 at 3:17 AM, Joel Sherrill  wrote:
>>> Thanks. I will try to deal with this Monday.
>>>
>>> My specs patches are not ready to push to gcc so I need to focus on
>>> just the parts to make x86_64 right.
>>>
>>> On Fri, May 18, 2018 at 3:41 PM, Amaan Cheval 
>>> wrote:

 To be clear, I applied this patch (with my fixes) on the 7.3 release
 through the RSB to test, not on GCC's master branch.

 > to add i386/rtemself64.h

 What you sent in this email thread adds rtemself64.h already. Do you
 mean you'd like to split the commits up or something?

 The only changes I made on top of yours were:

 - Readd "rtems.h" to config.gcc
 - Fix comments

 I've attached the patch file I used within the RSB here (sorry if you
 meant a patch of _just_ the fixes I made on top of yours, this is just
 the cumulative diff I used to patch GCC 7.3 to test).

 Regards,

 On Fri, May 18, 2018 at 7:00 PM, Joel Sherrill  wrote:
 >
 >
 >
 > On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval 
 > wrote:
 >>
 >> I just compiled my local fixed copy (adding rtems.h back in) and
 >> there's good news! With the patch, the x86_64 compile stub works with
 >> a blank bsp_specs file!
 >
 >
 > Awesome!
 >
 > Can you send me your changes as a patch? I am thinking I need to make
 > sure we agree on what the gcc master for x86_64-rtems looks like.
 >
 > Apparently I owe committing a patch to add i386/rtemself64.h since it is
 > missing on the master. And the comment is wrong.  What else?
 >
 >> On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval 
 >> wrote:
 >> > Hey!
 >> >
 >> > Thanks so much for sharing this, it's quite useful to put your
 >> > earlier
 >> > email[1] about minimzing the bsp_specs in context.
 >> >
 >> > From looking ahead a bit without testing (still compiling), the patch
 >> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it
 >> > defines
 >> > __TMC_END__ which crtbegin.o has left undefined for eg.) and possibly
 >> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs entirely
 >> > (see here[2]).
 >>
 >> Just noticed that ENDFILE_SPEC already includes crtend in i386elf.h,
 >> so there's no need for this change.
 >>
 >> >
 >> > I've also left some comments inline below.
 >> >
 >> > +1 on upstreaming this into GCC (making sure it also backports to 7.3
 >> > for simplicity, so we don't need to write a 7.3-specific patch for
 >> > the
 >> > RSB as well) with a few additons (at least for the x86_64 target, to
 >> > try to have an empty bsp_specs to begin with).
 >> >
 >> > [1] https://lists.rtems.org/pipermail/devel/2018-May/021430.html
 >> > [2]
 >> >
 >> > https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-01-compile-stub/bsps/x86_64/amd64/start/bsp_specs
 >> >
 >> > On Wed, May 16, 2018 at 8:46 PM, Joel Sherrill 
 >> > wrote:
 >> >> ---
 >> >>  gcc/config.gcc|  2 +-
 >> >>  gcc/config/arm/rtems.h|  4 
 >> >>  gcc/config/bfin/rtems.h   |  4 
 >> >>  gcc/config/i386/rtemself.h|  6 +-
 >> >>  

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

2018-07-08 Thread Amaan Cheval
To make my previous email clearer, here's what I meant with the
"minimal" GCC patch required (attached).

To manually test, you can place gcc-STARTFILE_SPEC.patch in
$RSB/rtems/patches/ and then "git apply rsb-startfile.diff" to the RSB
repo. Then build GCC and confirm that "x86_64-rtems5-gcc -dumpspecs"
includes crti and crtbegin in the startfile susbtitution.

Let me know if we aim to have this GCC work done before merging the
x86_64 BSP (see
https://lists.rtems.org/pipermail/devel/2018-July/022388.html) so I
can leave bsp_specs in or clear it out accordingly?

For now, I'm going to leave it in.

On Fri, Jul 6, 2018 at 10:46 AM, Amaan Cheval  wrote:
> Hey, Joel!
>
> The x86_64 BSP currently uses an empty bsp_specs file contingent on
> (at least the x86-64 parts of) this email thread's patch making it
> upstream to GCC, and making their way into the RSB.
>
> 2 options:
> - 1. Make the upstream GCC commit (at least the parts adding
> rtemself64.h, editing config.gcc, and "#if 0"ing out
> gcc/config/rtems.h)
> - 2. Use a bsp_specs in the new BSP for the merge now, and empty it out later
>
> I can test and send you an x86_64 specific patch for GCC if you'd
> like. Or if you prefer to have all the work together, we can go with
> #2.
>
> Let me know!
>
> On Sat, May 19, 2018 at 3:17 AM, Joel Sherrill  wrote:
>> Thanks. I will try to deal with this Monday.
>>
>> My specs patches are not ready to push to gcc so I need to focus on
>> just the parts to make x86_64 right.
>>
>> On Fri, May 18, 2018 at 3:41 PM, Amaan Cheval 
>> wrote:
>>>
>>> To be clear, I applied this patch (with my fixes) on the 7.3 release
>>> through the RSB to test, not on GCC's master branch.
>>>
>>> > to add i386/rtemself64.h
>>>
>>> What you sent in this email thread adds rtemself64.h already. Do you
>>> mean you'd like to split the commits up or something?
>>>
>>> The only changes I made on top of yours were:
>>>
>>> - Readd "rtems.h" to config.gcc
>>> - Fix comments
>>>
>>> I've attached the patch file I used within the RSB here (sorry if you
>>> meant a patch of _just_ the fixes I made on top of yours, this is just
>>> the cumulative diff I used to patch GCC 7.3 to test).
>>>
>>> Regards,
>>>
>>> On Fri, May 18, 2018 at 7:00 PM, Joel Sherrill  wrote:
>>> >
>>> >
>>> >
>>> > On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval 
>>> > wrote:
>>> >>
>>> >> I just compiled my local fixed copy (adding rtems.h back in) and
>>> >> there's good news! With the patch, the x86_64 compile stub works with
>>> >> a blank bsp_specs file!
>>> >
>>> >
>>> > Awesome!
>>> >
>>> > Can you send me your changes as a patch? I am thinking I need to make
>>> > sure we agree on what the gcc master for x86_64-rtems looks like.
>>> >
>>> > Apparently I owe committing a patch to add i386/rtemself64.h since it is
>>> > missing on the master. And the comment is wrong.  What else?
>>> >
>>> >> On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval 
>>> >> wrote:
>>> >> > Hey!
>>> >> >
>>> >> > Thanks so much for sharing this, it's quite useful to put your
>>> >> > earlier
>>> >> > email[1] about minimzing the bsp_specs in context.
>>> >> >
>>> >> > From looking ahead a bit without testing (still compiling), the patch
>>> >> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it
>>> >> > defines
>>> >> > __TMC_END__ which crtbegin.o has left undefined for eg.) and possibly
>>> >> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs entirely
>>> >> > (see here[2]).
>>> >>
>>> >> Just noticed that ENDFILE_SPEC already includes crtend in i386elf.h,
>>> >> so there's no need for this change.
>>> >>
>>> >> >
>>> >> > I've also left some comments inline below.
>>> >> >
>>> >> > +1 on upstreaming this into GCC (making sure it also backports to 7.3
>>> >> > for simplicity, so we don't need to write a 7.3-specific patch for
>>> >> > the
>>> >> > RSB as well) with a few additons (at least for the x86_64 target, to
>>> >> > try to have an empty bsp_specs to begin with).
>>> >> >
>>> >> > [1] https://lists.rtems.org/pipermail/devel/2018-May/021430.html
>>> >> > [2]
>>> >> >
>>> >> > https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-01-compile-stub/bsps/x86_64/amd64/start/bsp_specs
>>> >> >
>>> >> > On Wed, May 16, 2018 at 8:46 PM, Joel Sherrill 
>>> >> > wrote:
>>> >> >> ---
>>> >> >>  gcc/config.gcc|  2 +-
>>> >> >>  gcc/config/arm/rtems.h|  4 
>>> >> >>  gcc/config/bfin/rtems.h   |  4 
>>> >> >>  gcc/config/i386/rtemself.h|  6 +-
>>> >> >>  gcc/config/i386/rtemself64.h  | 39
>>> >> >> +++
>>> >> >>  gcc/config/m68k/rtemself.h|  4 
>>> >> >>  gcc/config/microblaze/rtems.h |  4 
>>> >> >>  gcc/config/mips/rtems.h   |  4 
>>> >> >>  gcc/config/moxie/rtems.h  |  4 
>>> >> >>  gcc/config/nios2/rtems.h  |  4 
>>> >> >>  gcc/config/riscv/rtems.h  |  4 
>>> >> >>  gcc/config/rs6000/rtems.h |  5 +
>>> >> >>  gcc/config/rtems.h|  6 +-

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

2018-05-18 Thread Joel Sherrill
Thanks. I will try to deal with this Monday.

My specs patches are not ready to push to gcc so I need to focus on
just the parts to make x86_64 right.

On Fri, May 18, 2018 at 3:41 PM, Amaan Cheval 
wrote:

> To be clear, I applied this patch (with my fixes) on the 7.3 release
> through the RSB to test, not on GCC's master branch.
>
> > to add i386/rtemself64.h
>
> What you sent in this email thread adds rtemself64.h already. Do you
> mean you'd like to split the commits up or something?
>
> The only changes I made on top of yours were:
>
> - Readd "rtems.h" to config.gcc
> - Fix comments
>
> I've attached the patch file I used within the RSB here (sorry if you
> meant a patch of _just_ the fixes I made on top of yours, this is just
> the cumulative diff I used to patch GCC 7.3 to test).
>
> Regards,
>
> On Fri, May 18, 2018 at 7:00 PM, Joel Sherrill  wrote:
> >
> >
> >
> > On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval 
> > wrote:
> >>
> >> I just compiled my local fixed copy (adding rtems.h back in) and
> >> there's good news! With the patch, the x86_64 compile stub works with
> >> a blank bsp_specs file!
> >
> >
> > Awesome!
> >
> > Can you send me your changes as a patch? I am thinking I need to make
> > sure we agree on what the gcc master for x86_64-rtems looks like.
> >
> > Apparently I owe committing a patch to add i386/rtemself64.h since it is
> > missing on the master. And the comment is wrong.  What else?
> >
> >> On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval 
> >> wrote:
> >> > Hey!
> >> >
> >> > Thanks so much for sharing this, it's quite useful to put your earlier
> >> > email[1] about minimzing the bsp_specs in context.
> >> >
> >> > From looking ahead a bit without testing (still compiling), the patch
> >> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it defines
> >> > __TMC_END__ which crtbegin.o has left undefined for eg.) and possibly
> >> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs entirely
> >> > (see here[2]).
> >>
> >> Just noticed that ENDFILE_SPEC already includes crtend in i386elf.h,
> >> so there's no need for this change.
> >>
> >> >
> >> > I've also left some comments inline below.
> >> >
> >> > +1 on upstreaming this into GCC (making sure it also backports to 7.3
> >> > for simplicity, so we don't need to write a 7.3-specific patch for the
> >> > RSB as well) with a few additons (at least for the x86_64 target, to
> >> > try to have an empty bsp_specs to begin with).
> >> >
> >> > [1] https://lists.rtems.org/pipermail/devel/2018-May/021430.html
> >> > [2]
> >> > https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-01-
> compile-stub/bsps/x86_64/amd64/start/bsp_specs
> >> >
> >> > On Wed, May 16, 2018 at 8:46 PM, Joel Sherrill 
> wrote:
> >> >> ---
> >> >>  gcc/config.gcc|  2 +-
> >> >>  gcc/config/arm/rtems.h|  4 
> >> >>  gcc/config/bfin/rtems.h   |  4 
> >> >>  gcc/config/i386/rtemself.h|  6 +-
> >> >>  gcc/config/i386/rtemself64.h  | 39
> >> >> +++
> >> >>  gcc/config/m68k/rtemself.h|  4 
> >> >>  gcc/config/microblaze/rtems.h |  4 
> >> >>  gcc/config/mips/rtems.h   |  4 
> >> >>  gcc/config/moxie/rtems.h  |  4 
> >> >>  gcc/config/nios2/rtems.h  |  4 
> >> >>  gcc/config/riscv/rtems.h  |  4 
> >> >>  gcc/config/rs6000/rtems.h |  5 +
> >> >>  gcc/config/rtems.h|  6 +-
> >> >>  gcc/config/sh/rtems.h |  4 
> >> >>  gcc/config/sh/rtemself.h  |  4 
> >> >>  gcc/config/sparc/rtemself.h   |  4 
> >> >>  gcc/config/v850/rtems.h   |  4 
> >> >>  17 files changed, 103 insertions(+), 3 deletions(-)
> >> >>  create mode 100644 gcc/config/i386/rtemself64.h
> >> >>
> >> >> diff --git a/gcc/config.gcc b/gcc/config.gcc
> >> >> index d509800..de27e5c 100644
> >> >> --- a/gcc/config.gcc
> >> >> +++ b/gcc/config.gcc
> >> >> @@ -1499,7 +1499,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 rtems.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/rtemself64.h"
> >> >
> >> > In rebasing with upstream, this commit must have silently mistakenly
> >> > also dropped rtems.h (which my patch earlier added to support the
> >> > -qrtems, -qnolinkcmds, etc. flags).
> >> >
> >> >> ;;
> >> >>  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"
> >> >> diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
> >> >> 

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

2018-05-18 Thread Amaan Cheval
To be clear, I applied this patch (with my fixes) on the 7.3 release
through the RSB to test, not on GCC's master branch.

> to add i386/rtemself64.h

What you sent in this email thread adds rtemself64.h already. Do you
mean you'd like to split the commits up or something?

The only changes I made on top of yours were:

- Readd "rtems.h" to config.gcc
- Fix comments

I've attached the patch file I used within the RSB here (sorry if you
meant a patch of _just_ the fixes I made on top of yours, this is just
the cumulative diff I used to patch GCC 7.3 to test).

Regards,

On Fri, May 18, 2018 at 7:00 PM, Joel Sherrill  wrote:
>
>
>
> On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval 
> wrote:
>>
>> I just compiled my local fixed copy (adding rtems.h back in) and
>> there's good news! With the patch, the x86_64 compile stub works with
>> a blank bsp_specs file!
>
>
> Awesome!
>
> Can you send me your changes as a patch? I am thinking I need to make
> sure we agree on what the gcc master for x86_64-rtems looks like.
>
> Apparently I owe committing a patch to add i386/rtemself64.h since it is
> missing on the master. And the comment is wrong.  What else?
>
>> On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval 
>> wrote:
>> > Hey!
>> >
>> > Thanks so much for sharing this, it's quite useful to put your earlier
>> > email[1] about minimzing the bsp_specs in context.
>> >
>> > From looking ahead a bit without testing (still compiling), the patch
>> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it defines
>> > __TMC_END__ which crtbegin.o has left undefined for eg.) and possibly
>> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs entirely
>> > (see here[2]).
>>
>> Just noticed that ENDFILE_SPEC already includes crtend in i386elf.h,
>> so there's no need for this change.
>>
>> >
>> > I've also left some comments inline below.
>> >
>> > +1 on upstreaming this into GCC (making sure it also backports to 7.3
>> > for simplicity, so we don't need to write a 7.3-specific patch for the
>> > RSB as well) with a few additons (at least for the x86_64 target, to
>> > try to have an empty bsp_specs to begin with).
>> >
>> > [1] https://lists.rtems.org/pipermail/devel/2018-May/021430.html
>> > [2]
>> > https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-01-compile-stub/bsps/x86_64/amd64/start/bsp_specs
>> >
>> > On Wed, May 16, 2018 at 8:46 PM, Joel Sherrill  wrote:
>> >> ---
>> >>  gcc/config.gcc|  2 +-
>> >>  gcc/config/arm/rtems.h|  4 
>> >>  gcc/config/bfin/rtems.h   |  4 
>> >>  gcc/config/i386/rtemself.h|  6 +-
>> >>  gcc/config/i386/rtemself64.h  | 39
>> >> +++
>> >>  gcc/config/m68k/rtemself.h|  4 
>> >>  gcc/config/microblaze/rtems.h |  4 
>> >>  gcc/config/mips/rtems.h   |  4 
>> >>  gcc/config/moxie/rtems.h  |  4 
>> >>  gcc/config/nios2/rtems.h  |  4 
>> >>  gcc/config/riscv/rtems.h  |  4 
>> >>  gcc/config/rs6000/rtems.h |  5 +
>> >>  gcc/config/rtems.h|  6 +-
>> >>  gcc/config/sh/rtems.h |  4 
>> >>  gcc/config/sh/rtemself.h  |  4 
>> >>  gcc/config/sparc/rtemself.h   |  4 
>> >>  gcc/config/v850/rtems.h   |  4 
>> >>  17 files changed, 103 insertions(+), 3 deletions(-)
>> >>  create mode 100644 gcc/config/i386/rtemself64.h
>> >>
>> >> diff --git a/gcc/config.gcc b/gcc/config.gcc
>> >> index d509800..de27e5c 100644
>> >> --- a/gcc/config.gcc
>> >> +++ b/gcc/config.gcc
>> >> @@ -1499,7 +1499,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 rtems.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/rtemself64.h"
>> >
>> > In rebasing with upstream, this commit must have silently mistakenly
>> > also dropped rtems.h (which my patch earlier added to support the
>> > -qrtems, -qnolinkcmds, etc. flags).
>> >
>> >> ;;
>> >>  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"
>> >> diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
>> >> index 1123f4a..e79ce90 100644
>> >> --- a/gcc/config/arm/rtems.h
>> >> +++ b/gcc/config/arm/rtems.h
>> >> @@ -34,3 +34,7 @@
>> >>  } while (0)
>> >>
>> >>  #define ARM_DEFAULT_SHORT_ENUMS false
>> >> +
>> >> +#undef STARTFILE_SPEC
>> >> +#define STARTFILE_SPEC "\
>> >> +%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
>> >> diff --git a/gcc/config/bfin/rtems.h b/gcc/config/bfin/rtems.h
>> >> index 6a9a41f..28a69b9 100644
>> >> --- 

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

2018-05-18 Thread Joel Sherrill
On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval 
wrote:

> I just compiled my local fixed copy (adding rtems.h back in) and
> there's good news! With the patch, the x86_64 compile stub works with
> a blank bsp_specs file!
>

Awesome!

Can you send me your changes as a patch? I am thinking I need to make
sure we agree on what the gcc master for x86_64-rtems looks like.

Apparently I owe committing a patch to add i386/rtemself64.h since it is
missing on the master. And the comment is wrong.  What else?

On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval 
> wrote:
> > Hey!
> >
> > Thanks so much for sharing this, it's quite useful to put your earlier
> > email[1] about minimzing the bsp_specs in context.
> >
> > From looking ahead a bit without testing (still compiling), the patch
> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it defines
> > __TMC_END__ which crtbegin.o has left undefined for eg.) and possibly
> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs entirely
> > (see here[2]).
>
> Just noticed that ENDFILE_SPEC already includes crtend in i386elf.h,
> so there's no need for this change.
>
> >
> > I've also left some comments inline below.
> >
> > +1 on upstreaming this into GCC (making sure it also backports to 7.3
> > for simplicity, so we don't need to write a 7.3-specific patch for the
> > RSB as well) with a few additons (at least for the x86_64 target, to
> > try to have an empty bsp_specs to begin with).
> >
> > [1] https://lists.rtems.org/pipermail/devel/2018-May/021430.html
> > [2] https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-01-
> compile-stub/bsps/x86_64/amd64/start/bsp_specs
> >
> > On Wed, May 16, 2018 at 8:46 PM, Joel Sherrill  wrote:
> >> ---
> >>  gcc/config.gcc|  2 +-
> >>  gcc/config/arm/rtems.h|  4 
> >>  gcc/config/bfin/rtems.h   |  4 
> >>  gcc/config/i386/rtemself.h|  6 +-
> >>  gcc/config/i386/rtemself64.h  | 39 ++
> +
> >>  gcc/config/m68k/rtemself.h|  4 
> >>  gcc/config/microblaze/rtems.h |  4 
> >>  gcc/config/mips/rtems.h   |  4 
> >>  gcc/config/moxie/rtems.h  |  4 
> >>  gcc/config/nios2/rtems.h  |  4 
> >>  gcc/config/riscv/rtems.h  |  4 
> >>  gcc/config/rs6000/rtems.h |  5 +
> >>  gcc/config/rtems.h|  6 +-
> >>  gcc/config/sh/rtems.h |  4 
> >>  gcc/config/sh/rtemself.h  |  4 
> >>  gcc/config/sparc/rtemself.h   |  4 
> >>  gcc/config/v850/rtems.h   |  4 
> >>  17 files changed, 103 insertions(+), 3 deletions(-)
> >>  create mode 100644 gcc/config/i386/rtemself64.h
> >>
> >> diff --git a/gcc/config.gcc b/gcc/config.gcc
> >> index d509800..de27e5c 100644
> >> --- a/gcc/config.gcc
> >> +++ b/gcc/config.gcc
> >> @@ -1499,7 +1499,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 rtems.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/rtemself64.h"
> >
> > In rebasing with upstream, this commit must have silently mistakenly
> > also dropped rtems.h (which my patch earlier added to support the
> > -qrtems, -qnolinkcmds, etc. flags).
> >
> >> ;;
> >>  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"
> >> diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
> >> index 1123f4a..e79ce90 100644
> >> --- a/gcc/config/arm/rtems.h
> >> +++ b/gcc/config/arm/rtems.h
> >> @@ -34,3 +34,7 @@
> >>  } while (0)
> >>
> >>  #define ARM_DEFAULT_SHORT_ENUMS false
> >> +
> >> +#undef STARTFILE_SPEC
> >> +#define STARTFILE_SPEC "\
> >> +%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
> >> diff --git a/gcc/config/bfin/rtems.h b/gcc/config/bfin/rtems.h
> >> index 6a9a41f..28a69b9 100644
> >> --- a/gcc/config/bfin/rtems.h
> >> +++ b/gcc/config/bfin/rtems.h
> >> @@ -31,3 +31,7 @@
> >>builtin_assert ("system=rtems"); \
> >>  }  \
> >>while (0)
> >> +
> >> +#undef STARTFILE_SPEC
> >> +#define STARTFILE_SPEC "\
> >> +%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
> >> diff --git a/gcc/config/i386/rtemself.h b/gcc/config/i386/rtemself.h
> >> index 65e8dad..3a09354 100644
> >> --- a/gcc/config/i386/rtemself.h
> >> +++ b/gcc/config/i386/rtemself.h
> >> @@ -1,4 +1,4 @@
> >> -/* Definitions for rtems targeting an ix86 using ELF.
> >> +/* Definitions for rtems targeting an x86_64 using ELF.
> >
> > I think you meant to have this comment in rtemself64.h, which says
> > ix86 currently?
> >
> >> Copyright (C) 

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

2018-05-18 Thread Amaan Cheval
I just compiled my local fixed copy (adding rtems.h back in) and
there's good news! With the patch, the x86_64 compile stub works with
a blank bsp_specs file!

On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval  wrote:
> Hey!
>
> Thanks so much for sharing this, it's quite useful to put your earlier
> email[1] about minimzing the bsp_specs in context.
>
> From looking ahead a bit without testing (still compiling), the patch
> may need an ENDFILE_SPEC definition as well for "crtend.o" (it defines
> __TMC_END__ which crtbegin.o has left undefined for eg.) and possibly
> "crtn.o", at least to eliminate the x86_64 port's bsp_specs entirely
> (see here[2]).

Just noticed that ENDFILE_SPEC already includes crtend in i386elf.h,
so there's no need for this change.

>
> I've also left some comments inline below.
>
> +1 on upstreaming this into GCC (making sure it also backports to 7.3
> for simplicity, so we don't need to write a 7.3-specific patch for the
> RSB as well) with a few additons (at least for the x86_64 target, to
> try to have an empty bsp_specs to begin with).
>
> [1] https://lists.rtems.org/pipermail/devel/2018-May/021430.html
> [2] 
> https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-01-compile-stub/bsps/x86_64/amd64/start/bsp_specs
>
> On Wed, May 16, 2018 at 8:46 PM, Joel Sherrill  wrote:
>> ---
>>  gcc/config.gcc|  2 +-
>>  gcc/config/arm/rtems.h|  4 
>>  gcc/config/bfin/rtems.h   |  4 
>>  gcc/config/i386/rtemself.h|  6 +-
>>  gcc/config/i386/rtemself64.h  | 39 +++
>>  gcc/config/m68k/rtemself.h|  4 
>>  gcc/config/microblaze/rtems.h |  4 
>>  gcc/config/mips/rtems.h   |  4 
>>  gcc/config/moxie/rtems.h  |  4 
>>  gcc/config/nios2/rtems.h  |  4 
>>  gcc/config/riscv/rtems.h  |  4 
>>  gcc/config/rs6000/rtems.h |  5 +
>>  gcc/config/rtems.h|  6 +-
>>  gcc/config/sh/rtems.h |  4 
>>  gcc/config/sh/rtemself.h  |  4 
>>  gcc/config/sparc/rtemself.h   |  4 
>>  gcc/config/v850/rtems.h   |  4 
>>  17 files changed, 103 insertions(+), 3 deletions(-)
>>  create mode 100644 gcc/config/i386/rtemself64.h
>>
>> diff --git a/gcc/config.gcc b/gcc/config.gcc
>> index d509800..de27e5c 100644
>> --- a/gcc/config.gcc
>> +++ b/gcc/config.gcc
>> @@ -1499,7 +1499,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 rtems.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/rtemself64.h"
>
> In rebasing with upstream, this commit must have silently mistakenly
> also dropped rtems.h (which my patch earlier added to support the
> -qrtems, -qnolinkcmds, etc. flags).
>
>> ;;
>>  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"
>> diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
>> index 1123f4a..e79ce90 100644
>> --- a/gcc/config/arm/rtems.h
>> +++ b/gcc/config/arm/rtems.h
>> @@ -34,3 +34,7 @@
>>  } while (0)
>>
>>  #define ARM_DEFAULT_SHORT_ENUMS false
>> +
>> +#undef STARTFILE_SPEC
>> +#define STARTFILE_SPEC "\
>> +%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
>> diff --git a/gcc/config/bfin/rtems.h b/gcc/config/bfin/rtems.h
>> index 6a9a41f..28a69b9 100644
>> --- a/gcc/config/bfin/rtems.h
>> +++ b/gcc/config/bfin/rtems.h
>> @@ -31,3 +31,7 @@
>>builtin_assert ("system=rtems"); \
>>  }  \
>>while (0)
>> +
>> +#undef STARTFILE_SPEC
>> +#define STARTFILE_SPEC "\
>> +%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
>> diff --git a/gcc/config/i386/rtemself.h b/gcc/config/i386/rtemself.h
>> index 65e8dad..3a09354 100644
>> --- a/gcc/config/i386/rtemself.h
>> +++ b/gcc/config/i386/rtemself.h
>> @@ -1,4 +1,4 @@
>> -/* Definitions for rtems targeting an ix86 using ELF.
>> +/* Definitions for rtems targeting an x86_64 using ELF.
>
> I think you meant to have this comment in rtemself64.h, which says
> ix86 currently?
>
>> Copyright (C) 1996-2018 Free Software Foundation, Inc.
>> Contributed by Joel Sherrill (j...@oarcorp.com).
>>
>> @@ -33,3 +33,7 @@
>> builtin_assert ("system=rtems");\
>>  }  \
>>while (0)
>> +
>> +#undef STARTFILE_SPEC
>> +#define STARTFILE_SPEC "\
>> +%{!nostdlib: %{!qrtems: crt0.o%s} crtbegin.o%s}"
>> diff --git a/gcc/config/i386/rtemself64.h b/gcc/config/i386/rtemself64.h
>> new file mode 100644
>> index 000..34e5937
>> --- /dev/null
>> +++ b/gcc/config/i386/rtemself64.h
>> @@ -0,0 +1,39 @@
>> +/* 

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

2018-05-17 Thread Amaan Cheval
Hey!

Thanks so much for sharing this, it's quite useful to put your earlier
email[1] about minimzing the bsp_specs in context.

>From looking ahead a bit without testing (still compiling), the patch
may need an ENDFILE_SPEC definition as well for "crtend.o" (it defines
__TMC_END__ which crtbegin.o has left undefined for eg.) and possibly
"crtn.o", at least to eliminate the x86_64 port's bsp_specs entirely
(see here[2]).

I've also left some comments inline below.

+1 on upstreaming this into GCC (making sure it also backports to 7.3
for simplicity, so we don't need to write a 7.3-specific patch for the
RSB as well) with a few additons (at least for the x86_64 target, to
try to have an empty bsp_specs to begin with).

[1] https://lists.rtems.org/pipermail/devel/2018-May/021430.html
[2] 
https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-01-compile-stub/bsps/x86_64/amd64/start/bsp_specs

On Wed, May 16, 2018 at 8:46 PM, Joel Sherrill  wrote:
> ---
>  gcc/config.gcc|  2 +-
>  gcc/config/arm/rtems.h|  4 
>  gcc/config/bfin/rtems.h   |  4 
>  gcc/config/i386/rtemself.h|  6 +-
>  gcc/config/i386/rtemself64.h  | 39 +++
>  gcc/config/m68k/rtemself.h|  4 
>  gcc/config/microblaze/rtems.h |  4 
>  gcc/config/mips/rtems.h   |  4 
>  gcc/config/moxie/rtems.h  |  4 
>  gcc/config/nios2/rtems.h  |  4 
>  gcc/config/riscv/rtems.h  |  4 
>  gcc/config/rs6000/rtems.h |  5 +
>  gcc/config/rtems.h|  6 +-
>  gcc/config/sh/rtems.h |  4 
>  gcc/config/sh/rtemself.h  |  4 
>  gcc/config/sparc/rtemself.h   |  4 
>  gcc/config/v850/rtems.h   |  4 
>  17 files changed, 103 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/config/i386/rtemself64.h
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index d509800..de27e5c 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1499,7 +1499,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 rtems.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/rtemself64.h"

In rebasing with upstream, this commit must have silently mistakenly
also dropped rtems.h (which my patch earlier added to support the
-qrtems, -qnolinkcmds, etc. flags).

> ;;
>  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"
> diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
> index 1123f4a..e79ce90 100644
> --- a/gcc/config/arm/rtems.h
> +++ b/gcc/config/arm/rtems.h
> @@ -34,3 +34,7 @@
>  } while (0)
>
>  #define ARM_DEFAULT_SHORT_ENUMS false
> +
> +#undef STARTFILE_SPEC
> +#define STARTFILE_SPEC "\
> +%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
> diff --git a/gcc/config/bfin/rtems.h b/gcc/config/bfin/rtems.h
> index 6a9a41f..28a69b9 100644
> --- a/gcc/config/bfin/rtems.h
> +++ b/gcc/config/bfin/rtems.h
> @@ -31,3 +31,7 @@
>builtin_assert ("system=rtems"); \
>  }  \
>while (0)
> +
> +#undef STARTFILE_SPEC
> +#define STARTFILE_SPEC "\
> +%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
> diff --git a/gcc/config/i386/rtemself.h b/gcc/config/i386/rtemself.h
> index 65e8dad..3a09354 100644
> --- a/gcc/config/i386/rtemself.h
> +++ b/gcc/config/i386/rtemself.h
> @@ -1,4 +1,4 @@
> -/* Definitions for rtems targeting an ix86 using ELF.
> +/* Definitions for rtems targeting an x86_64 using ELF.

I think you meant to have this comment in rtemself64.h, which says
ix86 currently?

> Copyright (C) 1996-2018 Free Software Foundation, Inc.
> Contributed by Joel Sherrill (j...@oarcorp.com).
>
> @@ -33,3 +33,7 @@
> builtin_assert ("system=rtems");\
>  }  \
>while (0)
> +
> +#undef STARTFILE_SPEC
> +#define STARTFILE_SPEC "\
> +%{!nostdlib: %{!qrtems: crt0.o%s} crtbegin.o%s}"
> diff --git a/gcc/config/i386/rtemself64.h b/gcc/config/i386/rtemself64.h
> new file mode 100644
> index 000..34e5937
> --- /dev/null
> +++ b/gcc/config/i386/rtemself64.h
> @@ -0,0 +1,39 @@
> +/* Definitions for rtems targeting an ix86 using ELF.

See above.

> +   Copyright (C) 1996-2018 Free Software Foundation, Inc.
> +   Contributed by Joel Sherrill (j...@oarcorp.com).
> +
> +   This file is part of GCC.
> +
> +   GCC is free software; you can redistribute it and/or modify it
> +   under the terms of the GNU General Public License as published
> +   by the Free Software Foundation; either version 3, or (at your
> +   option) any later version.
> +
> +   GCC is 

[PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

2018-05-16 Thread Joel Sherrill
---
 gcc/config.gcc|  2 +-
 gcc/config/arm/rtems.h|  4 
 gcc/config/bfin/rtems.h   |  4 
 gcc/config/i386/rtemself.h|  6 +-
 gcc/config/i386/rtemself64.h  | 39 +++
 gcc/config/m68k/rtemself.h|  4 
 gcc/config/microblaze/rtems.h |  4 
 gcc/config/mips/rtems.h   |  4 
 gcc/config/moxie/rtems.h  |  4 
 gcc/config/nios2/rtems.h  |  4 
 gcc/config/riscv/rtems.h  |  4 
 gcc/config/rs6000/rtems.h |  5 +
 gcc/config/rtems.h|  6 +-
 gcc/config/sh/rtems.h |  4 
 gcc/config/sh/rtemself.h  |  4 
 gcc/config/sparc/rtemself.h   |  4 
 gcc/config/v850/rtems.h   |  4 
 17 files changed, 103 insertions(+), 3 deletions(-)
 create mode 100644 gcc/config/i386/rtemself64.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index d509800..de27e5c 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1499,7 +1499,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 rtems.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/rtemself64.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"
diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
index 1123f4a..e79ce90 100644
--- a/gcc/config/arm/rtems.h
+++ b/gcc/config/arm/rtems.h
@@ -34,3 +34,7 @@
 } while (0)
 
 #define ARM_DEFAULT_SHORT_ENUMS false
+
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC "\
+%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
diff --git a/gcc/config/bfin/rtems.h b/gcc/config/bfin/rtems.h
index 6a9a41f..28a69b9 100644
--- a/gcc/config/bfin/rtems.h
+++ b/gcc/config/bfin/rtems.h
@@ -31,3 +31,7 @@
   builtin_assert ("system=rtems"); \
 }  \
   while (0)
+
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC "\
+%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
diff --git a/gcc/config/i386/rtemself.h b/gcc/config/i386/rtemself.h
index 65e8dad..3a09354 100644
--- a/gcc/config/i386/rtemself.h
+++ b/gcc/config/i386/rtemself.h
@@ -1,4 +1,4 @@
-/* Definitions for rtems targeting an ix86 using ELF.
+/* Definitions for rtems targeting an x86_64 using ELF.
Copyright (C) 1996-2018 Free Software Foundation, Inc.
Contributed by Joel Sherrill (j...@oarcorp.com).
 
@@ -33,3 +33,7 @@
builtin_assert ("system=rtems");\
 }  \
   while (0)
+
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC "\
+%{!nostdlib: %{!qrtems: crt0.o%s} crtbegin.o%s}"
diff --git a/gcc/config/i386/rtemself64.h b/gcc/config/i386/rtemself64.h
new file mode 100644
index 000..34e5937
--- /dev/null
+++ b/gcc/config/i386/rtemself64.h
@@ -0,0 +1,39 @@
+/* Definitions for rtems targeting an ix86 using ELF.
+   Copyright (C) 1996-2018 Free Software Foundation, Inc.
+   Contributed by Joel Sherrill (j...@oarcorp.com).
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
+
+/* Specify predefined symbols in preprocessor.  */
+
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+   builtin_define ("__rtems__");   \
+   builtin_define ("__USE_INIT_FINI__");   \
+   builtin_assert ("system=rtems");\
+}  \
+  while (0)
+
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC "\
+%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
diff --git a/gcc/config/m68k/rtemself.h b/gcc/config/m68k/rtemself.h
index e18a06e..6f31aa5 100644
--- a/gcc/config/m68k/rtemself.h
+++ b/gcc/config/m68k/rtemself.h
@@ -36,3 +36,7 @@
builtin_assert ("system=rtems");