dl06 - tms570 variant failures
Hi The build of all BSPs looks a lot better thanks to the patch Sebastian pushed. Only the tms570 variants fail to build. They end with this: error: mv -f spqreslib/.deps/spqreslib-init.Tpo spqreslib/.deps/spqreslib-init.Po elf:check_file: /data/home/joel/rtems-work/tools/5/bin/../lib/gcc/arm-rtems5/7.3.0/../../../../arm-rtems5/lib/libc.a:lib_a-_Exit.o@23794: Mixed data types not allowed (LSB/MSB). gmake[5]: *** [dl06.rap] Error 10 --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a
Hi Chris! I currently have code like this in c/src/lib/libbsp/x86_64/amd64/Makefile.am: librtemsbsp_a_SOURCES += ../../../../../../bsps/x86_64/amd64/interrupts/handlers.c # XXX: Needed to use GCC "interrupt" attribute directives - can we pass these # flags only for the handlers.c source file (compile to an object file first and # then link with the rest for librtemsbsp.a?) librtemsbsp_a_CFLAGS = -mgeneral-regs-only The CFLAGS arg is required to allow us to use "__attribute__((interrupt))" to setup interrupt handlers in C. (See [1] and ctrl+f "interrupt" for more.) Is there a way to not force the CFLAGS for _all_ of librtemsbsp, but to limit it only to handlers.c? If not, is the above code something that would be acceptable to have upstream? [1] https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function-Attributes ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a
On Tue, Jul 31, 2018 at 2:52 PM, Amaan Cheval wrote: > Hi Chris! > > I currently have code like this in c/src/lib/libbsp/x86_64/amd64/ > Makefile.am: > > librtemsbsp_a_SOURCES += > ../../../../../../bsps/x86_64/amd64/interrupts/handlers.c > # XXX: Needed to use GCC "interrupt" attribute directives - can we > pass these > # flags only for the handlers.c source file (compile to an object > file first and > # then link with the rest for librtemsbsp.a?) > librtemsbsp_a_CFLAGS = -mgeneral-regs-only > > The CFLAGS arg is required to allow us to use > "__attribute__((interrupt))" to setup interrupt handlers in C. (See > [1] and ctrl+f "interrupt" for more.) > > Is there a way to not force the CFLAGS for _all_ of librtemsbsp, but > to limit it only to handlers.c? > > If not, is the above code something that would be acceptable to have > upstream? > > [1] https://gcc.gnu.org/onlinedocs/gcc/x86-Function- > Attributes.html#x86-Function-Attributes Are we basically talking about the outermost layer of your interrupt dispatching? Have you looked at the basic approach taken by the other ports? They end up switching the stack pointer to a dedicated stack on the outermost interrupt and, if a context switch/dispatch is needed, arrange for the interrupted task to call _Thread_Dispatch.But tinker with its stack so some registers are saved and it looks like it made the call itself. If you can do it in C, I am ok with an attribute. I just don't think you can pull off all the stack and return to dispatch magic that way. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a
Hm, I'm not sure what to look for in the other ports specifically, really. The BSP porting documentation doesn't have a section on interrupts, so I'm doing this on more of an "as it comes up" basis. What I've got right now (the interrupt handlers in C) are what I need for calibrating the APIC timer (through the PIT) - so simply hooking IRQ0 (for the timer) and IRQ7 (spurious vector), since those are needed for the timer work to continue. What constitutes as a requirement for basic interrupt support? On Wed, Aug 1, 2018, 1:29 AM Joel Sherrill wrote: > > > On Tue, Jul 31, 2018 at 2:52 PM, Amaan Cheval > wrote: > >> Hi Chris! >> >> I currently have code like this in >> c/src/lib/libbsp/x86_64/amd64/Makefile.am: >> >> librtemsbsp_a_SOURCES += >> ../../../../../../bsps/x86_64/amd64/interrupts/handlers.c >> # XXX: Needed to use GCC "interrupt" attribute directives - can we >> pass these >> # flags only for the handlers.c source file (compile to an object >> file first and >> # then link with the rest for librtemsbsp.a?) >> librtemsbsp_a_CFLAGS = -mgeneral-regs-only >> >> The CFLAGS arg is required to allow us to use >> "__attribute__((interrupt))" to setup interrupt handlers in C. (See >> [1] and ctrl+f "interrupt" for more.) >> >> Is there a way to not force the CFLAGS for _all_ of librtemsbsp, but >> to limit it only to handlers.c? >> >> If not, is the above code something that would be acceptable to have >> upstream? >> >> [1] >> https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function-Attributes > > > Are we basically talking about the outermost layer of your interrupt > dispatching? > > > Have you looked at the basic approach taken by the other ports? They end > up switching the stack pointer to a dedicated stack on the outermost > interrupt > and, if a context switch/dispatch is needed, arrange for the interrupted > task to call _Thread_Dispatch.But tinker with its stack so some registers > are saved and it looks like it made the call itself. > > If you can do it in C, I am ok with an attribute. I just don't think you > can pull off all the stack and return to dispatch magic that way. > > --joel > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a
On Tue, Jul 31, 2018 at 3:05 PM, Amaan Cheval wrote: > Hm, I'm not sure what to look for in the other ports specifically, really. > The BSP porting documentation doesn't have a section on interrupts, so I'm > doing this on more of an "as it comes up" basis. > > What I've got right now (the interrupt handlers in C) are what I need for > calibrating the APIC timer (through the PIT) - so simply hooking IRQ0 (for > the timer) and IRQ7 (spurious vector), since those are needed for the timer > work to continue. > > What constitutes as a requirement for basic interrupt support? > There used to be a generic porting guide. I can see that this particular section has bit rotted some but the interrupt dispatching section. Some of this will have evolved to support SMP and fine grained locking but the pseudo-code here will give you a push toward the right line of thinking: https://docs.rtems.org/releases/rtemsdocs-4.10.2/share/rtems/html/porting/porting00034.html The idea is that you need to ensure RTEMS knows it is inside an interrupt and the current locking scheme (old was dispatching, new is ...) is honored. The ARM and PowerPC (plus RISCV) are good ports to look at for how SMP plays into this. But the CPU supplement is thin for their interrupt processing. This is the CPU Architecture supplement section for the m68k. This is a relatively simple architecture to describe. There is also a section for the i386 which reads similarly. https://docs.rtems.org/branches/master/cpu-supplement/m68xxx_and_coldfire.html#interrupt-processing Personally, I find the m68k a fairly easy processor to read assembly in. Look at cpukit/score/cpu/m68k/cpu_asm.S and _ISR_Handler to see what is done there w/o SMP. On the m68k _ISR_Handler is directly put into the vector table. But this isn't the most similar example for you. For the i386 (better example), it is in bsps/i386/shared/irq/irq_asm.S with the same name. There _ISR_Handler is installed via the DISTINCT_INTERRUPT_ENTRY macros at the bottom of the file where some prologue jumps to the common _ISR_Handler and then the actions are similar. Usually _ISR_Handler type of code ends up invoking a PIC decode method in normal C without an interrupt attribute. Long and multi-architecture answer but maybe that makes sense. The goal in ticker.exe is to take a number of tick interrupts which don't schedule and then take one that does -- it schedules a preemption of the idle thread. Hope this helps. --joel > > On Wed, Aug 1, 2018, 1:29 AM Joel Sherrill wrote: > >> >> >> On Tue, Jul 31, 2018 at 2:52 PM, Amaan Cheval >> wrote: >> >>> Hi Chris! >>> >>> I currently have code like this in c/src/lib/libbsp/x86_64/amd64/ >>> Makefile.am: >>> >>> librtemsbsp_a_SOURCES += >>> ../../../../../../bsps/x86_64/amd64/interrupts/handlers.c >>> # XXX: Needed to use GCC "interrupt" attribute directives - can we >>> pass these >>> # flags only for the handlers.c source file (compile to an object >>> file first and >>> # then link with the rest for librtemsbsp.a?) >>> librtemsbsp_a_CFLAGS = -mgeneral-regs-only >>> >>> The CFLAGS arg is required to allow us to use >>> "__attribute__((interrupt))" to setup interrupt handlers in C. (See >>> [1] and ctrl+f "interrupt" for more.) >>> >>> Is there a way to not force the CFLAGS for _all_ of librtemsbsp, but >>> to limit it only to handlers.c? >>> >>> If not, is the above code something that would be acceptable to have >>> upstream? >>> >>> [1] https://gcc.gnu.org/onlinedocs/gcc/x86-Function- >>> Attributes.html#x86-Function-Attributes >> >> >> Are we basically talking about the outermost layer of your interrupt >> dispatching? >> >> >> Have you looked at the basic approach taken by the other ports? They end >> up switching the stack pointer to a dedicated stack on the outermost >> interrupt >> and, if a context switch/dispatch is needed, arrange for the interrupted >> task to call _Thread_Dispatch.But tinker with its stack so some registers >> are saved and it looks like it made the call itself. >> >> If you can do it in C, I am ok with an attribute. I just don't think you >> can pull off all the stack and return to dispatch magic that way. >> >> --joel >> >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Initial implemantation commit
From: Danxue Huang <36866155+dh0...@users.noreply.github.com>
---
.gitignore | 2 +
README.md | 2 +
gen_rst_from_makedoc.py | 125
rst.py | 104
strcmp.rst | 47 ++
5 files changed, 280 insertions(+)
create mode 100644 .gitignore
create mode 100644 README.md
create mode 100755 gen_rst_from_makedoc.py
create mode 100644 rst.py
create mode 100644 strcmp.rst
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..9f90354
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,2 @@
+.idea/*
+__pycache__/*
diff --git a/README.md b/README.md
new file mode 100644
index 000..8ebb224
--- /dev/null
+++ b/README.md
@@ -0,0 +1,2 @@
+# NewlibMarkup2SphinxConvertorPrivate
+(PRIVATE) This repo contains code for NewlibMarkup2SphinxConvertorPrivate.
diff --git a/gen_rst_from_makedoc.py b/gen_rst_from_makedoc.py
new file mode 100755
index 000..da69c80
--- /dev/null
+++ b/gen_rst_from_makedoc.py
@@ -0,0 +1,125 @@
+#!/usr/bin/env python
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2018 Danxue Huang (danxue.hu...@gmail.com)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# 1. Redistributions of source code must retain the above copyright notice,
+# this list of conditions and the following disclaimer.
+#
+# 2. Redistributions in binary form must reproduce the above copyright notice,
+# this list of conditions and the following disclaimer in the documentation
+# and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+#
+
+
+import argparse
+import re
+import rst
+
+
+def is_command(s):
+"""
+A command is a single word of at least 3 characters, all uppercase
+:param s: input string
+:return: True if s is a single command, otherwise False
+"""
+return True if re.match('^[A-Z_]{3,}\s*$', s) else False
+
+
+def extract_comments(content):
+"""
+Extract content inside of /* */
+:param content: input file content
+:return: extracted comments
+"""
+comments = ''
+comments_match = re.match('/\*(\*(?!/)|[^*])*\*/', content)
+if comments_match:
+wrapped_comments = comments_match.group()
+comments = wrapped_comments.lstrip('/*').rstrip('*/').lstrip().rstrip()
+return comments
+
+
+def extract_command_and_text(content):
+"""
+Extract command and text from input string content
+:param content: input string containing command and text
+:return: a tuple containing command and text
+"""
+command = ''
+text = ''
+command_text_dict = {}
+for line in content.splitlines():
+if is_command(line):
+if command and text:
+command_text_dict[command] = text
+command = line.rstrip()
+text = ''
+else:
+text += line + '\n'
+return command_text_dict
+
+
+def generate_rst(command_text_dict):
+rst_str = ''
+for command, text in command_text_dict.items():
+rst_str += rst.get_command_processor(command)(command, text)
+return rst_str
+
+
+def get_parser():
+parser = argparse.ArgumentParser(
+description='Convert newlib style markup to rst markup'
+)
+parser.add_argument(
+'-s',
+'--source_file_dir',
+type=str,
+help='Source file directory with newlib style comments',
+)
+parser.add_argument(
+'-d',
+'--dest_file_dir',
+type=str,
+help='Destination directory for converted rst markup file',
+)
+return parser
+
+
+def main(source_file_dir, dest_file_dir):
+with open(source_file_dir, 'r') as source_file, open(dest_file_dir, 'w')
as dest_file:
+file_content = source_file.read()
+
+# Get comments inside of /* */
+comments = extract_comments(file_content)
+
+# Parse comments
+command_text_dict = extract_command_and_text(comments)
+
+
Re: dl06 - tms570 variant failures
On 31/07/18 21:17, Joel Sherrill wrote: Hi The build of all BSPs looks a lot better thanks to the patch Sebastian pushed. Only the tms570 variants fail to build. They end with this: error: mv -f spqreslib/.deps/spqreslib-init.Tpo spqreslib/.deps/spqreslib-init.Po elf:check_file: /data/home/joel/rtems-work/tools/5/bin/../lib/gcc/arm-rtems5/7.3.0/../../../../arm-rtems5/lib/libc.a:lib_a-_Exit.o@23794: Mixed data types not allowed (LSB/MSB). gmake[5]: *** [dl06.rap] Error 10 Is this a new error? -- 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: dl06 - tms570 variant failures
On 01/08/2018 15:26, Sebastian Huber wrote: > On 31/07/18 21:17, Joel Sherrill wrote: >> Hi >> >> The build of all BSPs looks a lot better thanks to the patch >> Sebastian pushed. Only the tms570 variants fail to build. >> They end with this: >> >> error: mv -f spqreslib/.deps/spqreslib-init.Tpo >> spqreslib/.deps/spqreslib-init.Po >> elf:check_file: >> /data/home/joel/rtems-work/tools/5/bin/../lib/gcc/arm-rtems5/7.3.0/../../../../arm-rtems5/lib/libc.a:lib_a-_Exit.o@23794: >> Mixed data types not allowed (LSB/MSB). >> gmake[5]: *** [dl06.rap] Error 10 > > Is this a new error? > #3401 Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
