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