Re: Where does the content of release report come from?

Hi Chris, Thank you so much for your instruction, I would write these two python modules for ticket list and tickets at first. Best, Dannie On Thu, May 24, 2018 at 2:15 PM, Chris Johns wrote: > On 25/5/18 12:52 am, Joel Sherrill wrote: > > I suggested in irc yesterday that having an outline to

Re: [GSoC] Ways to make the x86_64 port work with UEFI

On Fri, May 25, 2018, 12:11 PM Amaan Cheval wrote: > Hey! Could you link me to some code that you used for the Deos setup > you mentioned? > My understanding is that the -shared option can link static archives > to create a "shared" library in the sense that it doesn't include the > usual crt0 ru

Re: [GSoC] Ways to make the x86_64 port work with UEFI

Hey! Could you link me to some code that you used for the Deos setup you mentioned? My understanding is that the -shared option can link static archives to create a "shared" library in the sense that it doesn't include the usual crt0 runtime environment and whatnot, but the code within is still pos

Re: [GSoC] Ways to make the x86_64 port work with UEFI

On Fri, May 25, 2018, 11:15 AM Amaan Cheval wrote: > Hey! > > Skippable details about how FreeBSD handles the UEFI boot process! > > > > Having looked into it a bit more, my understanding of how FreeBSD > handles thi

Re: [GSoC] Ways to make the x86_64 port work with UEFI

Hey! Skippable details about how FreeBSD handles the UEFI boot process! Having looked into it a bit more, my understanding of how FreeBSD handles this process is: - They build a two-stage bootloader for EFI, called b

Re: Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

Am 25.05.2018 um 17:14 schrieb Joel Sherrill: > > > On Fri, May 25, 2018 at 10:09 AM, Amaan Cheval > wrote: > > Hi! > > I don't know the specifics of the thing you're talking about here, > so others should definitely weigh in on that if they can, but

Re: Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

On Fri, May 25, 2018 at 10:09 AM, Amaan Cheval wrote: > Hi! > > I don't know the specifics of the thing you're talking about here, so > others should definitely weigh in on that if they can, but regarding the > header file; the include syntax used (, as opposed to "ssp.h") is > the one used for s

Re: Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

Hi! I don't know the specifics of the thing you're talking about here, so others should definitely weigh in on that if they can, but regarding the header file; the include syntax used (, as opposed to "ssp.h") is the one used for system header files (for eg. vs "my_header.h"). I see 2 possibilit

Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

Hi all, While cross-compiling fio for RTEMS, by default in the compiler call > -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 options are used which raises the following error: > /home/uka_in/development/benchmark/sandbox/5/lib/gcc/arm-rtems5/7.3.0/include/ssp/unistd.h:38:10: > fatal error: ssp.h: No

Re: Covoar address to line to DWARF updates.

On Fri, 25 May 2018, 09:26 Vijay Kumar Banerjee, wrote: > > > On Fri, 25 May 2018, 02:52 Chris Johns, wrote: > >> On 25/5/18 7:11 am, Vijay Kumar Banerjee wrote: >> > On Fri, 25 May 2018, 00:35 Joel Sherrill, > > > wrote: >> > On Thu, May 24, 2018, 10:43 AM Vijay Kumar

Re: [PATCH] bsps/powerpc: Include to fix the build

On 25/05/18 15:22, Joel Sherrill wrote: It was dependent on the CFLAGS including a -D. Or some cases, the -mcpu option provided the CPU define expected. But virtex and ss555 provide -mcpu and -D options (now in bspopts.h) which are contradictory. This fixes (or covers up) most of an issue but

Re: [PATCH] bsps/powerpc: Include to fix the build

It was dependent on the CFLAGS including a -D. Or some cases, the -mcpu option provided the CPU define expected. But virtex and ss555 provide -mcpu and -D options (now in bspopts.h) which are contradictory. This fixes (or covers up) most of an issue but those two BSPs need their CPU flags adjusted

[PATCH] bsps/powerpc: Include to fix the build

This is a hack. The cpukit header file depends on defines provided by the BSP. Update #3425. --- bsps/powerpc/shared/start/bsp-start-zero.S | 2 +- bsps/powerpc/ss555/start/irq_asm.S | 1 + bsps/powerpc/ss555/start/vectors.S | 1 + 3 files changed, 3 insertions(+), 1 deletion(-)

[PATCH] score: Simplify _Objects_Name_to_string()

Do not use isprint() from since it depends on the heavy weight C locale implementation in Newlib. --- cpukit/score/src/objectgetnameasstring.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/cpukit/score/src/objectgetnameasstring.c b/cpukit/score/src/objectget

[PATCH] sim-scripts/qemu-malta.in: New file

--- sim-scripts/Makefile | 5 - sim-scripts/qemu-malta.in | 41 + 2 files changed, 45 insertions(+), 1 deletion(-) create mode 100644 sim-scripts/qemu-malta.in diff --git a/sim-scripts/Makefile b/sim-scripts/Makefile index 5a8a5d2..2ef4a1f 100644

[PATCH] sptests: Remove CONFIGURE_MILLISECONDS_PER_TICK

This configuration define is not supported. --- testsuites/sptests/sp69/init.c| 2 -- testsuites/sptests/sprmsched02/init.c | 2 -- 2 files changed, 4 deletions(-) diff --git a/testsuites/sptests/sp69/init.c b/testsuites/sptests/sp69/init.c index 6a5e139d34..38c40ccdf8 100644 --- a/testsu

[PATCH] config: Hide CONFIGURE_SCHEDULER_COUNT

Rename CONFIGURE_SCHEDULER_COUNT to _CONFIGURE_SCHEDULER_COUNT to emphasise that this is not a user configuration option. --- cpukit/include/rtems/confdefs.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confde

[PATCH] config: Hide CONFIGURE_INITIAL_EXTENSION_TABLE

Rename CONFIGURE_INITIAL_EXTENSION_TABLE to _CONFIGURE_INITIAL_EXTENSION_TABLE to emphasise that this is not a user configuration option. --- cpukit/include/rtems/confdefs.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/r