Re: [GSoC - x86_64] Minimal BSP to review

2018-07-08 Thread Amaan Cheval
Cool, I'll squash and post here again after I have (likely later today
or possibly early tomorrow) - I just noticed that using -O2 as an
optimization flag deterministically causes relocation errors, for eg.:

/home/amaan/repos/rtems/b-jul6/x86_64-rtems5/c/amd64/lib/libbsp/x86_64/
amd64/../../../../../../../../kernel/c/src/lib/libbsp/x86_64/amd64/../.
./../../../../bsps/shared/start/bspgetworkarea-default.c:54:(.text.bsp_
work_area_initialize+0xd): relocation truncated to fit: R_X86_64_32S ag
ainst symbol `RamSize' defined in *ABS* section in dhrystone.exe

Using -O0 reliably compiles for me, so for the merge patch, I'll leave
it at -O0 with an XXX comment.

Besides that, the only other potential blocker is the GCC patch
that'll allow the port to use an empty bsp_specs file - for now, I'm
leaving the bsp_specs it to remain functional.

On Fri, Jul 6, 2018 at 6:31 AM, Gedare Bloom  wrote:
> On Thu, Jul 5, 2018 at 10:02 AM, Amaan Cheval  wrote:
>> Hi!
>>
>> Yeah, the individual commits aren't logical at all. I just thought we
>> could review the actual code contents (in the "files changed" tab) on
>> Github (https://github.com/AmaanC/rtems-gsoc18/pull/1/files). Is this
>> what you meant by "final patchset"?
>>
>> Once this PR is polished up sufficiently, I can submit the squashed,
>> rebased commits to devel - that way we maintain the commit history for
>> how things progressed temporally, and still have the logical commits
>> we want upstream.
>>
>> If you'd prefer, I can squash on Github too (it just means I'd then
>> for a brief period not have the "daily" commit branch we aim to have
>> for GSoC, as I'd have to rebase to make changes instead of adding new
>> commits to the daily branch to indicate more "work done"). Let me know
>> if you prefer this!
>>
>
> You can do your squash/fixup on a new branch, and then restart your
> daily when needed. It is OK for the merger period to have less code
> activity.
>
> I took a quick look and commented on your github.
>
>> Thanks for catching the missing copyright in linkcmds!
>>
>> On Thu, Jul 5, 2018 at 7:16 PM, Sebastian Huber
>>  wrote:
>>> Hello Amaan,
>>>
>>> I think it is quite confusing to review the individual commit. I will review
>>> the final patch set.
>>>
>>> Just one thing:
>>>
>>> x86_64-rtems5-ld --verbose | head -n 20
>>> GNU ld (GNU Binutils) 2.30
>>>   Supported emulations:
>>>elf_x86_64
>>>elf_i386
>>>elf_iamcu
>>>elf32_x86_64
>>>elf_l1om
>>>elf_k1om
>>> using internal linker script:
>>> ==
>>> /* Script for -z combreloc: combine and sort reloc sections */
>>> /* Copyright (C) 2014-2018 Free Software Foundation, Inc.
>>>Copying and distribution of this script, with or without modification,
>>>are permitted in any medium without royalty provided the copyright
>>>notice and this notice are preserved.  */
>>> OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64",
>>>   "elf64-x86-64")
>>> OUTPUT_ARCH(i386:x86-64)
>>> ENTRY(_start)
>>> SEARCH_DIR("/build/rtems/5/x86_64-rtems5/lib");
>>>
>>> Please add the FSF notice to your file if necessary.
>>>
>>> --
>>> Sebastian Huber, embedded brains GmbH
>>>
>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>> Phone   : +49 89 189 47 41-16
>>> Fax : +49 89 189 47 41-09
>>> E-Mail  : sebastian.hu...@embedded-brains.de
>>> PGP : Public key available on request.
>>>
>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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 +-