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 <ged...@rtems.org> wrote:
> On Thu, Jul 5, 2018 at 10:02 AM, Amaan Cheval <amaan.che...@gmail.com> 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
>> <sebastian.hu...@embedded-brains.de> 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
