[PATCH] config: Hide CONFIGURE_INITIAL_EXTENSION_TABLE

2018-05-25 Thread Sebastian Huber 
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/rtems/confdefs.h
index 985a59e8ce..4ed9c193b0 100644
--- a/cpukit/include/rtems/confdefs.h
+++ b/cpukit/include/rtems/confdefs.h
@@ -2249,7 +2249,7 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
 #endif
   };
 
-  #define CONFIGURE_INITIAL_EXTENSION_TABLE Configuration_Initial_Extensions
+  #define _CONFIGURE_INITIAL_EXTENSION_TABLE Configuration_Initial_Extensions
   #define _CONFIGURE_NUMBER_OF_INITIAL_EXTENSIONS \
 RTEMS_ARRAY_SIZE(Configuration_Initial_Extensions)
 
@@ -2259,7 +2259,7 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
 RTEMS_SYSINIT_ORDER_MIDDLE
   );
 #else
-  #define CONFIGURE_INITIAL_EXTENSION_TABLE NULL
+  #define _CONFIGURE_INITIAL_EXTENSION_TABLE NULL
   #define _CONFIGURE_NUMBER_OF_INITIAL_EXTENSIONS 0
 #endif
 
@@ -3107,7 +3107,7 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
   #endif
 #endif
 _CONFIGURE_NUMBER_OF_INITIAL_EXTENSIONS,   /* number of static extensions 
*/
-CONFIGURE_INITIAL_EXTENSION_TABLE,/* pointer to static extensions 
*/
+_CONFIGURE_INITIAL_EXTENSION_TABLE,/* pointer to static extensions 
*/
 #if defined(RTEMS_MULTIPROCESSING)
   CONFIGURE_MULTIPROCESSING_TABLE,/* pointer to MP config table */
 #endif
-- 
2.13.6

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] config: Hide CONFIGURE_SCHEDULER_COUNT

2018-05-25 Thread Sebastian Huber 
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/confdefs.h
index 4ed9c193b0..7f3ffdff0d 100644
--- a/cpukit/include/rtems/confdefs.h
+++ b/cpukit/include/rtems/confdefs.h
@@ -976,10 +976,10 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
 CONFIGURE_SCHEDULER_TABLE_ENTRIES
   };
 
-  #define CONFIGURE_SCHEDULER_COUNT RTEMS_ARRAY_SIZE( _Scheduler_Table )
+  #define _CONFIGURE_SCHEDULER_COUNT RTEMS_ARRAY_SIZE( _Scheduler_Table )
 
   #if defined(RTEMS_SMP)
-const size_t _Scheduler_Count = CONFIGURE_SCHEDULER_COUNT;
+const size_t _Scheduler_Count = _CONFIGURE_SCHEDULER_COUNT;
 
 const Scheduler_Assignment _Scheduler_Initial_assignments[] = {
   #if defined(CONFIGURE_SCHEDULER_ASSIGNMENTS)
@@ -1864,7 +1864,7 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
   #define _CONFIGURE_MEMORY_FOR_PROXIES(_proxies) \
 _Configure_From_workspace((_proxies) \
   * (sizeof(Thread_Proxy_control) \
-+ THREAD_QUEUE_HEADS_SIZE(CONFIGURE_SCHEDULER_COUNT)))
++ THREAD_QUEUE_HEADS_SIZE(_CONFIGURE_SCHEDULER_COUNT)))
 
   #ifndef CONFIGURE_MP_MPCI_TABLE_POINTER
 #include 
@@ -2640,7 +2640,7 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
   ( \
 _Configure_Object_RAM(_tasks, sizeof(Configuration_Thread_control)) \
   + _Configure_From_workspace(_Configure_Max_Objects(_tasks) \
-* THREAD_QUEUE_HEADS_SIZE(CONFIGURE_SCHEDULER_COUNT)) \
+* THREAD_QUEUE_HEADS_SIZE(_CONFIGURE_SCHEDULER_COUNT)) \
   + _Configure_Max_Objects(_number_FP_tasks) \
 * _Configure_From_workspace(CONTEXT_FP_SIZE) \
   )
@@ -2961,7 +2961,7 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
 #if CONFIGURE_MAXIMUM_USER_EXTENSIONS > 0
   void *extensions[ CONFIGURE_MAXIMUM_USER_EXTENSIONS + 1 ];
 #endif
-Configuration_Scheduler_node Scheduler_nodes[ CONFIGURE_SCHEDULER_COUNT ];
+Configuration_Scheduler_node Scheduler_nodes[ _CONFIGURE_SCHEDULER_COUNT ];
 RTEMS_API_Control API_RTEMS;
 #ifdef RTEMS_POSIX_API
   POSIX_API_Control API_POSIX;
-- 
2.13.6

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] sptests: Remove CONFIGURE_MILLISECONDS_PER_TICK

2018-05-25 Thread Sebastian Huber 
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/testsuites/sptests/sp69/init.c
+++ b/testsuites/sptests/sp69/init.c
@@ -181,8 +181,6 @@ rtems_task Init(
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
 
-#define CONFIGURE_MILLISECONDS_PER_TICK 1
-
 #define CONFIGURE_MAXIMUM_TASKS 1
 #define CONFIGURE_MAXIMUM_PERIODS   1
 
diff --git a/testsuites/sptests/sprmsched02/init.c 
b/testsuites/sptests/sprmsched02/init.c
index 3834542622..f128818c82 100644
--- a/testsuites/sptests/sprmsched02/init.c
+++ b/testsuites/sptests/sprmsched02/init.c
@@ -104,8 +104,6 @@ rtems_task Init(
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
 
-#define CONFIGURE_MILLISECONDS_PER_TICK 1
-
 #define CONFIGURE_MAXIMUM_TASKS 1
 #define CONFIGURE_MAXIMUM_PERIODS   1
 
-- 
2.13.6

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2018-05-25 Thread Hesham Almatary 
---
 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
--- a/sim-scripts/Makefile
+++ b/sim-scripts/Makefile
@@ -7,7 +7,7 @@ SKYEYE_SCRIPTS=ant5206 bf537Stamp-skyeye csb337 csb350 csb360 
edb7312 \
 TSIM_SCRIPTS=erc32-tsim leon2-tsim leon3-tsim
 QEMU_SCRIPTS=pc386 qemuppc qemu-gumstix qemu-leon2 qemu-lm32_evr qemu-or1k \
   uC5282 lm3s6965 realview_pbx_a9_qemu realview_pbx_a9_qemu_smp \
-  xilinx_zynq_a9_qemu
+  xilinx_zynq_a9_qemu qemu-malta
 
 GENERATED_SCRIPTS=\
   ${GDBSIM_SCRIPTS} $(GDBSIM_SCRIPTS:%=%-gdb) \
@@ -54,6 +54,9 @@ uC5282: gdb-sim-run.in uC5282.in
 lm3s6965: gdb-sim-run.in lm3s6965.in
./mkrun no ARM arm lm3s6965
 
+qemu-malta: gdb-sim-run.in qemu-malta.in
+   ./mkrun no MIPS mips qemu-malta
+
 realview_pbx_a9_qemu: gdb-sim-run.in realview_pbx_a9_qemu.in
./mkrun no ARM arm realview_pbx_a9_qemu
 
diff --git a/sim-scripts/qemu-malta.in b/sim-scripts/qemu-malta.in
new file mode 100644
index 000..3ba88c2
--- /dev/null
+++ b/sim-scripts/qemu-malta.in
@@ -0,0 +1,41 @@
+#
+#  MIPS Malta BSP QEMU Support
+#
+
+bspUsesGDBSimulator="no"
+# bspGeneratesGDBCommands="yes"
+# bspSupportsGDBServerMode="yes"
+runBSP=NOT_OVERRIDDEN
+if [ ! -r ${runBSP} ] ; then
+  runBSP=qemu-system-mips
+fi
+bspNeedsDos2Unix="yes"
+
+runARGS()
+{
+  if [ ${coverage} = yes ] ; then
+COVERAGE_ARG="--exec-trace ${1}.cov"
+  fi
+
+  echo "-serial mon:stdio -serial /dev/null -net none -nographic -kernel ${1}"
+}
+
+checkBSPFaults()
+{
+  return 0
+}
+
+bspLimit()
+{
+  testname=$1
+  case ${testname} in
+*stackchk*)limit=5 ;;
+*fatal*)   limit=1 ;;
+*minimum*) limit=1 ;;
+*psxtime*) limit=270 ;;
+*) limit=60 ;;
+  esac
+  echo ${limit}
+}
+
+bspGeneratesDeviceTree="no"
-- 
2.7.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] score: Simplify _Objects_Name_to_string()

2018-05-25 Thread Sebastian Huber 
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/objectgetnameasstring.c
index 7a6177a124..f23b1599e1 100644
--- a/cpukit/score/src/objectgetnameasstring.c
+++ b/cpukit/score/src/objectgetnameasstring.c
@@ -21,7 +21,17 @@
 
 #include 
 
-#include 
+/*
+ * Do not use isprint() from  since this depends on the heavy weight
+ * C locale support of Newlib.
+ */
+static bool _Objects_Name_char_is_printable( char c )
+{
+  unsigned char uc;
+
+  uc = (unsigned char) c;
+  return uc >= ' ' && uc <= '~';
+}
 
 size_t _Objects_Name_to_string(
   Objects_Name  name,
@@ -55,7 +65,7 @@ size_t _Objects_Name_to_string(
   if ( s != NULL ) {
 while ( *s != '\0' ) {
   if ( i < buffer_size ) {
-*d = isprint((unsigned char) *s) ? *s : '*';
+*d = _Objects_Name_char_is_printable(*s) ? *s : '*';
 ++d;
   }
 
-- 
2.13.6

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2018-05-25 Thread Sebastian Huber 
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(-)

diff --git a/bsps/powerpc/shared/start/bsp-start-zero.S 
b/bsps/powerpc/shared/start/bsp-start-zero.S
index e87efff8c3..2df0241d71 100644
--- a/bsps/powerpc/shared/start/bsp-start-zero.S
+++ b/bsps/powerpc/shared/start/bsp-start-zero.S
@@ -20,9 +20,9 @@
  * http://www.rtems.org/license/LICENSE.
  */
 
+#include 
 #include 
 #include 
-#include 
 
.globl bsp_start_zero
.globl bsp_start_zero_begin
diff --git a/bsps/powerpc/ss555/start/irq_asm.S 
b/bsps/powerpc/ss555/start/irq_asm.S
index 52911c48e3..a78d7c35a5 100644
--- a/bsps/powerpc/ss555/start/irq_asm.S
+++ b/bsps/powerpc/ss555/start/irq_asm.S
@@ -22,6 +22,7 @@
  *  SPRG0 - RTEMS relies on that variable.
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/bsps/powerpc/ss555/start/vectors.S 
b/bsps/powerpc/ss555/start/vectors.S
index 35d2f23a30..0722b92892 100644
--- a/bsps/powerpc/ss555/start/vectors.S
+++ b/bsps/powerpc/ss555/start/vectors.S
@@ -13,6 +13,7 @@
  *  (c) 1999, Eric Valette vale...@crf.canon.fr
  */
 
+#include 
 #include 
 #include 
 #include 
-- 
2.13.6

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2018-05-25 Thread Joel Sherrill 
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.

On Fri, May 25, 2018, 7:35 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> 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(-)
>
> diff --git a/bsps/powerpc/shared/start/bsp-start-zero.S
> b/bsps/powerpc/shared/start/bsp-start-zero.S
> index e87efff8c3..2df0241d71 100644
> --- a/bsps/powerpc/shared/start/bsp-start-zero.S
> +++ b/bsps/powerpc/shared/start/bsp-start-zero.S
> @@ -20,9 +20,9 @@
>   * http://www.rtems.org/license/LICENSE.
>   */
>
> +#include 
>  #include 
>  #include 
> -#include 
>
> .globl bsp_start_zero
> .globl bsp_start_zero_begin
> diff --git a/bsps/powerpc/ss555/start/irq_asm.S
> b/bsps/powerpc/ss555/start/irq_asm.S
> index 52911c48e3..a78d7c35a5 100644
> --- a/bsps/powerpc/ss555/start/irq_asm.S
> +++ b/bsps/powerpc/ss555/start/irq_asm.S
> @@ -22,6 +22,7 @@
>   *  SPRG0 - RTEMS relies on that variable.
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/bsps/powerpc/ss555/start/vectors.S
> b/bsps/powerpc/ss555/start/vectors.S
> index 35d2f23a30..0722b92892 100644
> --- a/bsps/powerpc/ss555/start/vectors.S
> +++ b/bsps/powerpc/ss555/start/vectors.S
> @@ -13,6 +13,7 @@
>   *  (c) 1999, Eric Valette vale...@crf.canon.fr
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> --
> 2.13.6
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2018-05-25 Thread Sebastian Huber 

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 those two BSPs need 
their CPU flags adjusted.


I don't really care about these two BSPs. Are they still in use? My 
primary concern is that the powerpc build is currently broken.


--
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: Covoar address to line to DWARF updates.

2018-05-25 Thread Vijay Kumar Banerjee 
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 Banerjee
>> > mailto:vijaykumar9...@gmail.com>> wrote:
>> > On 24 May 2018 at 18:58, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com
>> > > wrote:
>> > On 24 May 2018 at 18:21, Gedare Bloom > > > wrote:
>> >
>> > Vijay,
>> >
>> > Please test Chris' modifications.
>> >
>> > On Thu, May 24, 2018 at 2:23 AM, Chris Johns <
>> chr...@rtems.org
>> > > wrote:
>> > > Hi,
>> > >
>> > > I have pushed my latest set of changes to my personal
>> repo to remove covoar
>> > > exec'ing addr2line and to directly use the DWARF
>> debug info.
>> > >
>> > > I have not been able to fully test the results
>> because I do not have a suitable
>> > > .exe and .cov pair with match source. The executable
>> and coverage data I have
>> > > received has helped but objdump fails because I do
>> not have the source in the
>> > > executable path so does not find the source.
>> > >
>> > > I would like to get these changes on to master as
>> soon as possible so if a
>> > > covoar built from my repo can be tested I can then
>> push the changes to master.
>> > >
>> > > I have added to RTEMS Tools an addr2line utility as I
>> needed a tool to test the
>> > > DWARF support I have added to the rtemstoolkit.
>> > >
>> > > The repo is
>> https://git.rtems.org/chrisj/rtems-tools.git and the changes are on
>> > > the branch 'covoar-dwarf'.
>> > >
>> >
>> >  Hello ,
>> > I have added the .cov trace file and the objdump output of
>> hello.exe
>> > that I'm getting.
>> > Is there anything else I should be doing to test it ?
>> > Shall I send the txt reports generated from covoar ?
>> >
>> >
>> > I merged your branch with my current working branch that's
>> > producing html reports.
>> > When I run in for samples/ I'm getting some report that looks
>> good.
>> > But when I run for the whole testsuites. It trips in the middle
>> after a
>> > lot of
>> > INFO messages. It shows the following error:
>> >
>> > ===
>> > .
>> > .
>> > .
>> > INFO: DesiredSymbols::createCoverageMap - Attempt to create
>> unified
>> > coverage maps for CSWTCH.1 with different sizes
>> >
>>  
>> (/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/libtests/mghttpd01/mghttpd01.exe/2148!=
>> >
>>  
>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/benchmarks/dhrystone/dhrystone.exe/16)
>> > error: SymbolTable::addSymbol: Different lengths for the symbol
>> CSWTCH.1
>> > (16 and 544)
>> > error: covoar failure exit code:
>>
>> Is this the error that stops covoar?
>>
>> yes
>> >
>> > This is the symbol loading picking up rodata merged into the text
>> segment.
>> > Chris know about this and it is on his to-do list.
>> >
>> > Can you ignore these and see how the results look?
>> >
>> > it doesn't show results, it exits in the middle with the error, even
>> before
>> > coverage starts generating reports.
>> >
>>
>> Is that the error message above?
>>
>> yes
>>
> I fetched the branch afresh then merged it.
I see the same error while running full testsuites.

>
> Chris
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

2018-05-25 Thread Udit agarwal 
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 such file or directory
>  #include 
>   ^~~
> compilation terminated.
> make: *** [crc/crc32c-arm64.o] Error 1
>
> However, ssp.h is in the same folder.
Without these options, only sys/unistd.h is included and not the
ssp/unistd.h. Any idea why these compiler opts are raising these error?

Also, FIO needs a BSP independent method for determining the size of RAM
for it's internal working.  I'm unable to figure out any such
implementation. Any help on this too, would be great.

Regards,
Udit agarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

2018-05-25 Thread Amaan Cheval 
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 possibilities:
- The project expects these files to be in a standard include directory
(such as /usr/include), which the compiler checks for system headers by
default
- You need to add the directory where ssp.h exists to the command-line
flags for the compiler, for eg. through "gcc -I. ssp.c" (assuming ssp.c
includes ssp.h, which exists in the same directory). See this for more:
https://gcc.gnu.org/onlinedocs/gcc-6.4.0/cpp/Search-Path.html


On Fri, May 25, 2018, 8:08 PM Udit agarwal  wrote:

> 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 such file or directory
>>  #include 
>>   ^~~
>> compilation terminated.
>> make: *** [crc/crc32c-arm64.o] Error 1
>>
>> However, ssp.h is in the same folder.
> Without these options, only sys/unistd.h is included and not the
> ssp/unistd.h. Any idea why these compiler opts are raising these error?
>
> Also, FIO needs a BSP independent method for determining the size of RAM
> for it's internal working.  I'm unable to figure out any such
> implementation. Any help on this too, would be great.
>
> Regards,
> Udit agarwal
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

2018-05-25 Thread 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 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 possibilities:
> - The project expects these files to be in a standard include directory
> (such as /usr/include), which the compiler checks for system headers by
> default
> - You need to add the directory where ssp.h exists to the command-line
> flags for the compiler, for eg. through "gcc -I. ssp.c" (assuming ssp.c
> includes ssp.h, which exists in the same directory). See this for more:
> https://gcc.gnu.org/onlinedocs/gcc-6.4.0/cpp/Search-Path.html
>

I don't have an ssp.h on my Centos system and don't think it is a standard
.h file at all.
It isn't from POSIX or C Library for sure.

If it is in their source tree, then it should be "ssp.h" (or something that
picks up the file)
and the use of <> is broken. It isn't a standard header file.

Change it to "". If it works, submit a patch upstream and cc me on it.
Hopefully
they will just accept the patch and it won't be a long discussion.

>
>
> On Fri, May 25, 2018, 8:08 PM Udit agarwal  wrote:
>
>> 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
>>> such file or directory
>>>  #include 
>>>   ^~~
>>> compilation terminated.
>>> make: *** [crc/crc32c-arm64.o] Error 1
>>>
>>> However, ssp.h is in the same folder.
>> Without these options, only sys/unistd.h is included and not the
>> ssp/unistd.h. Any idea why these compiler opts are raising these error?
>>
>> Also, FIO needs a BSP independent method for determining the size of RAM
>> for it's internal working.  I'm unable to figure out any such
>> implementation. Any help on this too, would be great.
>>
>> Regards,
>> Udit agarwal
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

2018-05-25 Thread Christian Mauderer 
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
> 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 possibilities:
> - The project expects these files to be in a standard include
> directory (such as /usr/include), which the compiler checks for
> system headers by default
> - You need to add the directory where ssp.h exists to the
> command-line flags for the compiler, for eg. through "gcc -I. ssp.c"
> (assuming ssp.c includes ssp.h, which exists in the same directory).
> See this for
> more: https://gcc.gnu.org/onlinedocs/gcc-6.4.0/cpp/Search-Path.html
> 
> 
> 
> I don't have an ssp.h on my Centos system and don't think it is a
> standard .h file at all.
> It isn't from POSIX or C Library for sure.
> 
> If it is in their source tree, then it should be "ssp.h" (or something
> that picks up the file)
> and the use of <> is broken. It isn't a standard header file.
> 
> Change it to "". If it works, submit a patch upstream and cc me on it.
> Hopefully
> they will just accept the patch and it won't be a long discussion. 
> 

Hello,

I'm not sure whether that is the right location to search for that bug.
Udit and I already had a discussion about this problem before he posted
it to the mailing list. The problem seemed odd for me so I suggested
that he should post it here.

The output that Udit posted here is a little short:


sh > LANG=en_US make V=1 CROSS_COMPILE=../../install/rtems/5/bin/arm-rtems5-
../../install/rtems/5/bin/arm-rtems5-gcc -o crc/crc32c-arm64.o
-std=gnu99 -Wwrite-strings -Wall -Wdeclaration-after-statement -g
-ffast-math  -D_GNU_SOURCE -include config-host.h -I. -I. -O3
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -DBITS_PER_LONG=32
-DFIO_VERSION='"fio-3.6-37-g1222"' -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DFIO_INTERNAL -DFIO_INC_DEBUG -c crc/crc32c-arm64.c
In file included from
/home/christian/rtems/rtems-bbb/install/rtems/5/arm-rtems5/include/sys/unistd.h:596:0,
 from
/home/christian/rtems/rtems-bbb/install/rtems/5/arm-rtems5/include/unistd.h:4,
 from
/home/christian/rtems/rtems-bbb/install/rtems/5/arm-rtems5/include/pthread.h:25,
 from crc/../os/os.h:7,
 from crc/crc32c-arm64.c:2:
/home/christian/rtems/rtems-bbb/install/rtems/5/lib/gcc/arm-rtems5/7.3.0/include/ssp/unistd.h:38:10:
fatal error: ssp.h: No such file or directory
 #include 
  ^~~
compilation terminated.
make: *** [Makefile:336: crc/crc32c-arm64.o] Error 1
sh >

(In case the formatting is lost due to the mail: You can find that
output here too:
https://gist.github.com/c-mauderer/5c4bf432b812b78b18bed859d4a7b59a

So that file is included from unistd.h. If you take a look at the path,
there is suddenly a jump from

   install/rtems/5/arm-rtems5/include/sys/unistd.h
to
   install/rtems/5/lib/gcc/arm-rtems5/7.3.0/include/ssp/ssp.h

That's really odd because in my install location, there is also a

   install/rtems/5/arm-rtems5/include/ssp/ssp.h

with correct include paths. The one in
gcc/arm-rtems5/7.3.0 has a header that says that "This file is part of
GCC" while the other one is derived from a NetBSD one and most likely
the one used in Newlib.

So the big question is: Why is the compiler using the wrong include
file? Note that the ssp.h is only included with the FORTIFY_SOURCE
options that Udit mentioned. I would expect that it happens for any
application that uses these options and includes pthread.h.

Best regards

Christian

> 
> 
> On Fri, May 25, 2018, 8:08 PM Udit agarwal  > wrote:
> 
> 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 such file or directory
>  #include 
>   ^~~
> compilation terminated.
> make: *** [crc/crc32c-arm64.o] Error 1
> 
> However, ssp.h is in the same folder.
> Without these options, only sys/unistd.h is included and not the
> ssp/unistd.h. Any idea why these compiler opts are raising these
> error?
> 
> Also, FIO needs a BSP independent method for determining the
> size of RAM for it's internal working.  I'm unable to figure out
> any such  implementation. Any help on th

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

2018-05-25 Thread Amaan Cheval 
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 boot1.efi and loader.efi[1]
- loader.efi is an interactive prompt which may autoboot, or a "boot
kernelImg" command can be used to load the actual kernel
- The kernel is loaded as an ELF through helper functions. The
command_boot[2] function drives this:
  - In brief, through calls go through:
command_boot -> mod_loadkld -> file_load ->
file_formats[i]->l_load (actually the loadfile function in
load_elf.c[3])
  - The loadfile function parses the program and section headers of
the ELF file (through more function detours that are not really
important)
  - Once the ELF has been loaded at the correct entry_addr that it
expects to be loaded at in memory, the l_exec[4] function is called,
which is actually elf64_exec in elf64_freebsd.c[5], at which hopefully
through trampolining magic, the control flow will transfer to the
kernel or ELF module



What this means for RTEMS if we go with gnu-efi is essentially 2
options, given that the objcopy method of converting from ELF->PE
requires the ELF to be a position-independent shared library:

- Using -fPIC to compile all of RTEMS, including the RTEMS user's
application code. This way we'd have librtemsbso.so, librtemscpu.so,
etc. which would then be linked into user_app.c through -fPIC and
-shared flags still, creating one singular hello.so, which can then
finally be converted into hello.efi and put on a FAT filesystem and
booted. This seems doable, but I'm fairly concerned about it further
complicating our build system and likely being quite singular in its
focus on EFI.

- The FreeBSD way of a (loader.efi) and a hello.exe (ELF64) put on
possibly the same partition on the FAT filesystem required for UEFI
application images anyway. The loader.efi can find the hello.exe file
through perhaps a config file it can read or by having a magic-name
like rtems.exe or something. This effectively means we need an ELF
dynamic linker / loader (akin to ld.so) within RTEMS' source. I think
using FreeBSD's code for this should be fine. One added benefit of
this method is that librtems* and user applications remain as ELF64s,
which in the future could also be used with Multiboot with a slightly
modified "loader" (i.e. one which generates the apt Multiboot magic
header, and boots the PC from 32-bit protected mode to 64-bit long
mode).

I prefer the latter approach personally. If both of these seem too
complicated, we can of course go back to considering generating the PE
header format in ASM the way Linux distros use EFISTUB and the code
Chris shared (as I mentioned in my original blog post) for wimboot.
Those approaches may be significantly simpler in a sense, but may
limit how we use UEFI Services - I'm not sure about the details of
this yet - I can investigate if y'all aren't fond of the option I laid
down above.

Let me know!

[1] 
https://www.freebsd.org/cgi/man.cgi?query=loader&apropos=0&sektion=8&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html
[2] 
https://github.com/freebsd/freebsd/blob/433bd38e3a0349f9f89f9d54594172c75b002b74/stand/common/boot.c#L53
[3] 
https://github.com/freebsd/freebsd/blob/d8596f6f687a64b994b065f3058155405dfc39db/stand/common/load_elf.c#L150
[4] 
https://github.com/freebsd/freebsd/blob/433bd38e3a0349f9f89f9d54594172c75b002b74/stand/common/boot.c#L107
[5] 
https://github.com/freebsd/freebsd/blob/d8596f6f687a64b994b065f3058155405dfc39db/stand/efi/loader/arch/amd64/elf64_freebsd.c#L93

On Sun, May 20, 2018 at 10:52 PM, Joel Sherrill  wrote:
>
>
> On Sun, May 20, 2018, 12:10 PM Amaan Cheval  wrote:
>>
>> On Sat, May 19, 2018 at 6:51 PM, Gedare Bloom  wrote:
>> > On Fri, May 18, 2018 at 5:53 PM, Joel Sherrill  wrote:
>> >>
>> >>
>> >> On Fri, May 18, 2018 at 3:24 PM, Amaan Cheval 
>> >> wrote:
>> >>>
>> >>> Hi everyone!
>> >>>
>> >>> I've written a quick blog post summarizing the options I've considered
>> >>> to make the x86_64 port work with UEFI firmware - the primary winner
>> >>> seems to be in my eyes to use "gnu-efi" and to add support for the
>> >>> target "pei-x86-64" (aliased to "efi-app-x86_64") to
>> >>> "x86_64-rtems5-objcopy" in binutils. I've submitted a patch for this
>> >>> here[1].
>> >>
>> >>
>> >> That patch is quite simple so shouldn't be a problem if this is the
>> >> direction
>> >> that gets consensus.
>> >>>
>> >>>
>> >>> The blog post is here:
>> >>> https://blog.whatthedude.com/post/uefi-app-options/
>> >>>
>> >>> I'd appreciate all feedback (and please do let me know if I haven't
>> >>> provided enough context)!
>> >>>
>> >>> Specifically, some concerns I'd like to discuss are:
>> >>>
>> >>> - Does everyone agree with me on choosing gnu-efi +

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

2018-05-25 Thread Joel Sherrill 
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 this process is:
> - They build a two-stage bootloader for EFI, called boot1.efi and
> loader.efi[1]
> - loader.efi is an interactive prompt which may autoboot, or a "boot
> kernelImg" command can be used to load the actual kernel
> - The kernel is loaded as an ELF through helper functions. The
> command_boot[2] function drives this:
>   - In brief, through calls go through:
> command_boot -> mod_loadkld -> file_load ->
> file_formats[i]->l_load (actually the loadfile function in
> load_elf.c[3])
>   - The loadfile function parses the program and section headers of
> the ELF file (through more function detours that are not really
> important)
>   - Once the ELF has been loaded at the correct entry_addr that it
> expects to be loaded at in memory, the l_exec[4] function is called,
> which is actually elf64_exec in elf64_freebsd.c[5], at which hopefully
> through trampolining magic, the control flow will transfer to the
> kernel or ELF module
>
>
> 
>
> What this means for RTEMS if we go with gnu-efi is essentially 2
> options, given that the objcopy method of converting from ELF->PE
> requires the ELF to be a position-independent shared library:
>
> - Using -fPIC to compile all of RTEMS, including the RTEMS user's
> application code. This way we'd have librtemsbso.so, librtemscpu.so,
> etc. which would then be linked into user_app.c through -fPIC and
> -shared flags still, creating one singular hello.so, which can then
> finally be converted into hello.efi and put on a FAT filesystem and
> booted. This seems doable, but I'm fairly concerned about it further
> complicating our build system and likely being quite singular in its
> focus on EFI.
>

I'm using PIC on the Deos BSP. RTEMS is still a .a and exes are linked with
our static libraries and Deos .so.

Unless the loader forces something, you can use PIC with no build system
changes.

note that thread local storage is different on i386 with and without PIC.

>
> - The FreeBSD way of a (loader.efi) and a hello.exe (ELF64) put on
> possibly the same partition on the FAT filesystem required for UEFI
> application images anyway. The loader.efi can find the hello.exe file
> through perhaps a config file it can read or by having a magic-name
> like rtems.exe or something. This effectively means we need an ELF
> dynamic linker / loader (akin to ld.so) within RTEMS' source. I think
> using FreeBSD's code for this should be fine. One added benefit of
> this method is that librtems* and user applications remain as ELF64s,
> which in the future could also be used with Multiboot with a slightly
> modified "loader" (i.e. one which generates the apt Multiboot magic
> header, and boots the PC from 32-bit protected mode to 64-bit long
> mode).
>
> I prefer the latter approach personally. If both of these seem too
> complicated, we can of course go back to considering generating the PE
> header format in ASM the way Linux distros use EFISTUB and the code
> Chris shared (as I mentioned in my original blog post) for wimboot.
> Those approaches may be significantly simpler in a sense, but may
> limit how we use UEFI Services - I'm not sure about the details of
> this yet - I can investigate if y'all aren't fond of the option I laid
> down above.
>
> Let me know!
>
> [1]
> https://www.freebsd.org/cgi/man.cgi?query=loader&apropos=0&sektion=8&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html
> [2]
> https://github.com/freebsd/freebsd/blob/433bd38e3a0349f9f89f9d54594172c75b002b74/stand/common/boot.c#L53
> [3]
> https://github.com/freebsd/freebsd/blob/d8596f6f687a64b994b065f3058155405dfc39db/stand/common/load_elf.c#L150
> [4]
> https://github.com/freebsd/freebsd/blob/433bd38e3a0349f9f89f9d54594172c75b002b74/stand/common/boot.c#L107
> [5]
> https://github.com/freebsd/freebsd/blob/d8596f6f687a64b994b065f3058155405dfc39db/stand/efi/loader/arch/amd64/elf64_freebsd.c#L93
>
> On Sun, May 20, 2018 at 10:52 PM, Joel Sherrill  wrote:
> >
> >
> > On Sun, May 20, 2018, 12:10 PM Amaan Cheval 
> wrote:
> >>
> >> On Sat, May 19, 2018 at 6:51 PM, Gedare Bloom  wrote:
> >> > On Fri, May 18, 2018 at 5:53 PM, Joel Sherrill 
> wrote:
> >> >>
> >> >>
> >> >> On Fri, May 18, 2018 at 3:24 PM, Amaan Cheval <
> amaan.che...@gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> Hi everyone!
> >> >>>
> >> >>> I've written a quick blog post summarizing the options I've
> considered
> >> >>> to make the x86_64 port work with UEFI firmware - the primary winner
> >> >>> seems to be in my eyes to use "gnu-efi" and to add support for the
> >> >>> target "pei-x86-64" (aliased to "efi-app-x86_64") to
> >> >>> "x86_64-rtems5-objcopy" in

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

2018-05-25 Thread Amaan Cheval 
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 position-dependent. Given that the PE image that EFI needs is
one that needs to be truly relocatable, this may not work - BUT, I've
only just noticed the ./gnuefi/reloc_x86_64.c file which seems to
handle some kinds of runtime relocations encoded within the converted
PE file, so maybe this will work after all. I'll continue to
investigate and let you know how it goes!

Regarding how TLS differs with PIC - could you elaborate? Is it
something we'll need to solve for if we go with the -fPIC option, or
is it something we need to keep in mind as a limitation, but isn't
really a blocker?

On Fri, May 25, 2018 at 10:13 PM, Joel Sherrill  wrote:
>
>
> 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 this process is:
>> - They build a two-stage bootloader for EFI, called boot1.efi and
>> loader.efi[1]
>> - loader.efi is an interactive prompt which may autoboot, or a "boot
>> kernelImg" command can be used to load the actual kernel
>> - The kernel is loaded as an ELF through helper functions. The
>> command_boot[2] function drives this:
>>   - In brief, through calls go through:
>> command_boot -> mod_loadkld -> file_load ->
>> file_formats[i]->l_load (actually the loadfile function in
>> load_elf.c[3])
>>   - The loadfile function parses the program and section headers of
>> the ELF file (through more function detours that are not really
>> important)
>>   - Once the ELF has been loaded at the correct entry_addr that it
>> expects to be loaded at in memory, the l_exec[4] function is called,
>> which is actually elf64_exec in elf64_freebsd.c[5], at which hopefully
>> through trampolining magic, the control flow will transfer to the
>> kernel or ELF module
>>
>>
>> 
>>
>> What this means for RTEMS if we go with gnu-efi is essentially 2
>> options, given that the objcopy method of converting from ELF->PE
>> requires the ELF to be a position-independent shared library:
>>
>> - Using -fPIC to compile all of RTEMS, including the RTEMS user's
>> application code. This way we'd have librtemsbso.so, librtemscpu.so,
>> etc. which would then be linked into user_app.c through -fPIC and
>> -shared flags still, creating one singular hello.so, which can then
>> finally be converted into hello.efi and put on a FAT filesystem and
>> booted. This seems doable, but I'm fairly concerned about it further
>> complicating our build system and likely being quite singular in its
>> focus on EFI.
>
>
> I'm using PIC on the Deos BSP. RTEMS is still a .a and exes are linked with
> our static libraries and Deos .so.
>
> Unless the loader forces something, you can use PIC with no build system
> changes.
>
> note that thread local storage is different on i386 with and without PIC.
>>
>>
>> - The FreeBSD way of a (loader.efi) and a hello.exe (ELF64) put on
>> possibly the same partition on the FAT filesystem required for UEFI
>> application images anyway. The loader.efi can find the hello.exe file
>> through perhaps a config file it can read or by having a magic-name
>> like rtems.exe or something. This effectively means we need an ELF
>> dynamic linker / loader (akin to ld.so) within RTEMS' source. I think
>> using FreeBSD's code for this should be fine. One added benefit of
>> this method is that librtems* and user applications remain as ELF64s,
>> which in the future could also be used with Multiboot with a slightly
>> modified "loader" (i.e. one which generates the apt Multiboot magic
>> header, and boots the PC from 32-bit protected mode to 64-bit long
>> mode).
>>
>> I prefer the latter approach personally. If both of these seem too
>> complicated, we can of course go back to considering generating the PE
>> header format in ASM the way Linux distros use EFISTUB and the code
>> Chris shared (as I mentioned in my original blog post) for wimboot.
>> Those approaches may be significantly simpler in a sense, but may
>> limit how we use UEFI Services - I'm not sure about the details of
>> this yet - I can investigate if y'all aren't fond of the option I laid
>> down above.
>>
>> Let me know!
>>
>> [1]
>> https://www.freebsd.org/cgi/man.cgi?query=loader&apropos=0&sektion=8&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html
>> [2]
>> https://github.com/freebsd/freebsd/blob/433bd38e3a0349f9f89f9d54594172c75b002b74/stand/common/boot.c#L53
>> [3]
>> https://github.com/freebsd/freebsd/blob/d8596f6f687a64b994b065f

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

2018-05-25 Thread Joel Sherrill 
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 runtime environment and whatnot, but the code within is
> still position-dependent. Given that the PE image that EFI needs is
> one that needs to be truly relocatable, this may not work - BUT, I've
> only just noticed the ./gnuefi/reloc_x86_64.c file which seems to
> handle some kinds of runtime relocations encoded within the converted
> PE file, so maybe this will work after all. I'll continue to
> investigate and let you know how it goes!
>

Deos isn't a good example except that you can compile with -fPIC and put
that code into a static library. Deos is a closed source Level A (man rated
flight) ARINC 653 RTOS. It's boot process reads configuration information
about each partition and associates .so's with each address space per the
configuration. It can't change after that.

The RTEMS exe is mostly linked as normal except to use some arguments to
say some symbols are from a shared library.

The base address of the exe is that of the provided virtual address space
with .data and .bss in their respective spaces.

And our entry point is in C so there is no asm before that. Great
simplification.


> Regarding how TLS differs with PIC - could you elaborate? Is it
> something we'll need to solve for if we go with the -fPIC option, or
> is it something we need to keep in mind as a limitation, but isn't
> really a blocker?
>

I don't think PIC changes the TLS mechanism on arm or PowerPC but on i386,
when not PIC the TLS base is in %gs and it's a subroutine call when PIC.
Just as well for Deos since they assume an application won't change the
segment register values.

Other than this one TLS difference, it is a normal exe to me. They just
magically provide their .so's before we run.

>
> On Fri, May 25, 2018 at 10:13 PM, Joel Sherrill  wrote:
> >
> >
> > 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 this process is:
> >> - They build a two-stage bootloader for EFI, called boot1.efi and
> >> loader.efi[1]
> >> - loader.efi is an interactive prompt which may autoboot, or a "boot
> >> kernelImg" command can be used to load the actual kernel
> >> - The kernel is loaded as an ELF through helper functions. The
> >> command_boot[2] function drives this:
> >>   - In brief, through calls go through:
> >> command_boot -> mod_loadkld -> file_load ->
> >> file_formats[i]->l_load (actually the loadfile function in
> >> load_elf.c[3])
> >>   - The loadfile function parses the program and section headers of
> >> the ELF file (through more function detours that are not really
> >> important)
> >>   - Once the ELF has been loaded at the correct entry_addr that it
> >> expects to be loaded at in memory, the l_exec[4] function is called,
> >> which is actually elf64_exec in elf64_freebsd.c[5], at which hopefully
> >> through trampolining magic, the control flow will transfer to the
> >> kernel or ELF module
> >>
> >>
> >>
> 
> >>
> >> What this means for RTEMS if we go with gnu-efi is essentially 2
> >> options, given that the objcopy method of converting from ELF->PE
> >> requires the ELF to be a position-independent shared library:
> >>
> >> - Using -fPIC to compile all of RTEMS, including the RTEMS user's
> >> application code. This way we'd have librtemsbso.so, librtemscpu.so,
> >> etc. which would then be linked into user_app.c through -fPIC and
> >> -shared flags still, creating one singular hello.so, which can then
> >> finally be converted into hello.efi and put on a FAT filesystem and
> >> booted. This seems doable, but I'm fairly concerned about it further
> >> complicating our build system and likely being quite singular in its
> >> focus on EFI.
> >
> >
> > I'm using PIC on the Deos BSP. RTEMS is still a .a and exes are linked
> with
> > our static libraries and Deos .so.
> >
> > Unless the loader forces something, you can use PIC with no build system
> > changes.
> >
> > note that thread local storage is different on i386 with and without PIC.
> >>
> >>
> >> - The FreeBSD way of a (loader.efi) and a hello.exe (ELF64) put on
> >> possibly the same partition on the FAT filesystem required for UEFI
> >> application images anyway. The loader.efi can find the hello.exe file
> >> through perhaps a config file it can read or by having a magic-name
> >> like rtems.exe or something. This effectively means we need an ELF
> >> dynamic linker / loader (akin to ld.so) within RTEMS

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

2018-05-25 Thread Dannie Huang 
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 show the intended
> goal
> > would be nice. Perhaps even a mock up of the result with limited
> content.
> >
> > Personally, I find writing without an outline hard so that may be my
> style showing.
>
> I think you maybe right :D
>
> I would prefer our efforts concentrate on fetching the needed data and
> getting
> it into an internal Python dict. For me the output is not important at this
> point in time.
>
> What we display is easy to see, go to the milestone page for a release that
> lists the tickets, this is the list of tickets to include in the release
> notes
> and then click on a ticket, that is the data to be presented. An outline
> is:
>
>  - Ticket List
>  - Tickets
>
> The format and layout will be determined once we have the data and we can
> review
> what it contains combined with how much effort we wish to invest. For
> example we
> may write XML output so the notes can be machine readable or we may
> generate
> ReST and build the notes using Sphinx. Note, the RSS feed contains some
> HTML
> fragments in it's XML structure which complications things.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel