[PATCH v2] x86_64/gcc: Add gcc patch for LIB_SPEC (rtems.h in gcc)

Adds -qnolinkcmds, -qrtems, and defaults to pass to linker, for gcc targeting x86_64. Corresponding gcc commit: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=602fa1e9d3ea5e87d4d6e17e3e91fc2647e42da3 --- rtems/config/5/rtems-x86_64.bset | 7 +++ 1 file changed, 7 insertions(+) diff --git a/rt

Re: [PATCH] x86_64/gcc: Add gcc patch for LIB_SPEC (rtems.h in gcc)

Realized that it makes more sense to apply the patch in the x86_64 buildset (rtems-source-builder/rtems/config/5/rtems-x86_64.bset) instead of the shared gcc config. v2 patch coming as soon as I can compile and verify that that works too (likely tomorrow). Sorry about the noise! On Sat, Apr 7, 201

[PATCH] x86_64/gcc: Add gcc patch for LIB_SPEC (rtems.h in gcc)

Adds -qnolinkcmds, -qrtems, and defaults to pass to linker, for gcc targeting x86_64. Corresponding gcc commit: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=602fa1e9d3ea5e87d4d6e17e3e91fc2647e42da3 --- rtems/config/tools/rtems-gcc-7.3.0-newlib-3.0.0.cfg | 3 +++ 1 file changed, 3 insertions(+)

Re: x86_64 port and BSP (GSoC 2018)

That definitely makes sense, yes. I'll look into the parts we need for ACPI and how we can match them up to ACPICA. I've added it to my proposal as a reminder / roadmap item of sorts for something to evaluate in during phase 1, since I believe the essential bits of ACPI will be involved during init

Re: x86_64 port and BSP (GSoC 2018)

On Fri, Apr 6, 2018 at 3:09 PM, Amaan Cheval wrote: > Thanks for sharing your thoughts! I did have a brief look since it's > mentioned in the original ticket, but I've left it in the bonus features > since from what I understand, a lot of the ACPI features to be implemented > are not really essen

Re: x86_64 port and BSP (GSoC 2018)

Thanks for sharing your thoughts! I did have a brief look since it's mentioned in the original ticket, but I've left it in the bonus features since from what I understand, a lot of the ACPI features to be implemented are not really essential. It should definitely be a resource to consider for the f

Re: x86_64 port and BSP (GSoC 2018)

I hate to pile on late but following the link to osdev.org in an earlier message led me to Google for something like Intel's reference implementation. https://github.com/acpica This os_specific directory has adapters for Linux, BSD, and Windows. I don't think there are that many methods in the OS

Re: Compiler flags --pipe

On Fri, Apr 6, 2018 at 4:25 AM, Mikhail Svetkin wrote: > Hi all, > > I am very interested in the flag --pipe. > Why we use --pipe instead of -pipe? > Why we use --pipe only for gcc and not for g++? > Can somebody explain me? > The choice of whether to use --pipe is being made by autoconf probes.

Re: x86_64 tools gcc error: unrecognized command line option '-qnolinkcmds'

If this is what you think is missing, feel free to submit a patch to gcc-patches@ and cc' myself and Sebastian. One of us will have to approve it and merge it. Good spot. $ git diff diff --git a/gcc/config.gcc b/gcc/config.gcc index 75d0ae8..f23fe4a 100644 --- a/gcc/config.gcc +++ b/gcc/config.gc

[PATCH 3/6] waf: Fix freebsd-to-rtems.py.

Update #3351 --- builder.py | 3 +++ freebsd-to-rtems.py | 3 ++- waf_libbsd.py | 7 +-- 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/builder.py b/builder.py index 2faf98d0..ac199a9b 100755 --- a/builder.py +++ b/builder.py @@ -677,3 +677,6 @@ class ModuleMana

[PATCH 5/6] freebsd-to-rtems.py: Use all modules.

Update #3351 --- builder.py | 8 ++-- freebsd-to-rtems.py | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/builder.py b/builder.py index ac199a9b..bb5791a8 100755 --- a/builder.py +++ b/builder.py @@ -674,8 +674,12 @@ class ModuleManager(object): self.co

[PATCH 4/6] waf: Remove module without sources.

There are no imported sources for a number of modules. Some of them doesn't even have the right paths for freebsd-org anymore. Therefore this patch removes the following modules: - dev_usb_add_on - dev_usb_bluetooth - dev_usb_controller_add_on - dev_usb_misc - dev_usb_storage_add_on - dev_usb_temp

libbsd: Make modules configurable via ini files.

Hello, also I had really bad luck with some patches today, I'll post these for feedback: This is a part of the changes that I plan in the context of https://devel.rtems.org/ticket/3351 The current version already allows to enable or disable modules in the libbsd using a configuration file in the

[PATCH 6/6] waf: Add configurations with different modules.

This allows multiple build configurations (buildsets) with different modules enabled. Update #3351 --- CONTRIBUTING.md | 7 ++- README.waf | 3 +- builder.py | 13 ++--- buildset/default.ini | 58 ++ buildset/sample.ini | 10 libbsd.py

Re: [PATCH 1/2] Fix bsp_init hook.

Writing patches at Friday is just not a good idea ... I found out why the silent drop of the exception is necessary: There is a file not found exception if the .lock-waf_linux2_build does not exist. This patch implements the alternative solution: Fixing the scope of contexts and env. ___

[PATCH v2] Fix bsp_init hook.

--- rtems.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rtems.py b/rtems.py index 713066d..6907709 100644 --- a/rtems.py +++ b/rtems.py @@ -89,6 +89,8 @@ def init(ctx, filters = None, version = None, long_commands = False, bsp_init = # rtems_long_commands = lo

[PATCH 2/2] Don't silently drop exception during init.

--- rtems.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rtems.py b/rtems.py index f974e25..af17dbd 100644 --- a/rtems.py +++ b/rtems.py @@ -139,8 +139,8 @@ def init(ctx, filters = None, version = None, long_commands = False, bsp_init = if bsp_init:

[PATCH 1/2] Fix bsp_init hook.

--- rtems.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rtems.py b/rtems.py index 713066d..f974e25 100644 --- a/rtems.py +++ b/rtems.py @@ -136,12 +136,12 @@ def init(ctx, filters = None, version = None, long_commands = False, bsp_init = else:

Re: [PATCH v3] Add bsp_init hook.

Am 06.04.2018 um 08:58 schrieb Chris Johns: > On 06/04/2018 16:54, Christian Mauderer wrote: >> --- >> rtems.py | 9 +++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) > > Pushed. Thank you. > > Chris > Hello Chris, I just noted a bug: I either have to move the bsp_init call inside

Compiler flags --pipe

Hi all, I am very interested in the flag --pipe. Why we use --pipe instead of -pipe? Why we use --pipe only for gcc and not for g++? Can somebody explain me? Thank you in advance. Best regards, Mikhail ___ devel mailing list devel@rtems.org http://list

Re: x86_64 tools gcc error: unrecognized command line option '-qnolinkcmds'

Whoops, I just realized that by rtems.h, you probably meant the top-level one[1], not the arch-specific one. That makes a lot more sense given that I see the GCC spec syntax with mention of qnolinkcmds in there too. I'll try recompiling the tools with the addition and send the GCC patch if that do

Re: x86_64 port and BSP (GSoC 2018)

Status update time! # Completed: [x] Get my QEMU environment setup - Documented on the RTEMS wiki[1] [x] Read more of RTEMS' no_cpu code, and the BSP porting guide - Read most of the guide - things have been in flux with the refactorings, but I think most of it makes sense, especially af

Re: sptests/splinkersets01

On 06/04/18 06:20, Chris Johns wrote: On 05/04/2018 22:47, Sebastian Huber wrote: On 05/04/18 14:39, Chris Johns wrote: Hi, Is there suppose to be a library created and then linked to the test? If so what purpose is it performing? It tests the normal use case of the linker sets. The sets a

x86_64 tools gcc error: unrecognized command line option '-qnolinkcmds'

As prep for my x86_64 port / BSP proposal, I'm building a stub port to compile with the x86_64 toolset to surface any features the tools may be missing. Here's an error I came across: make[1772]: Entering directory '/media/commonhdd/repos/rtems/b-no_cpu/x86_64-rtems5/c/no_ bsp/cpukit/score/cpu' x8

[PATCH] no_cpu/no_bsp: Fix path to bspgetworkarea.c in Makefile for libbsp.a

The file is now in ./c/src/lib/libbsp/shared/bspgetworkarea.c (note the lack of the startup directory). This would result in errors such as the following for anyone basing their BSP off of no_bsp: make[3]: *** No rule to make target '../../shared/startup/bspgetworkarea.c', needed by 'bspgetworkare