Re: Need help in building newlib
Hello Aditya Upadhyay, please don't send me e-mails directly. Use the devel@rtems.org mailing list instead. On 07/06/17 11:21, aditya upadhyay wrote: Hello Sebastian Huber, I am Aditya Upadhyay, selected in GSoC 2017, for RTEMS organization. My project is POSIX Compliance. I have to work on newlib where i have to port the code of some functions and have to add some header file from RTEMS. I have implemented inttypes.h and its related methods in rtems. There is already an inttypes.h in Newlib. Please fix this if something is missing. Please don't write code on your own if there exists already an implementation in FreeBSD, OpenBSD, NetBSD or bionic for this. Now i want to port it to the newlib. But i have no idea how to port it to the newlib. Even i have tried to build newlib using this, described here : https://sourceware.org/newlib/ but i am not able to build it correctly. Is there any changes to do while executing this command- ../newlib-2.2.0/configure --host=sun4 --target=m68k-aout Here target should be sparc-rtems4.12 and what should be the host ? I need initial help. Once i will get the things clear, i will move ahead to work. Any help will be greatly appreciable and much helpful for me. You can build the tool chain with the RSB (I guess this was already a part of the GSoC preparation). It has reporting features to show you exactly the commands used to produce the tool chain. You can then build it on your own using these commands. Please use a Git clone of Newlib for this kind of work. -- 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: RISC-V interrupts
On 06/06/17 18:58, Hesham Almatary wrote: Originally RTEMS had a one big linkcmd for each platform, which defines linker symbols (used in C code) and required sections. This has been improved with current BSPs (like ARM-based ones), by splitting up shared linkcmd parts (linkcmd base) and BSP specific ones that include the shared one. riscv_generic, given that it's old, follows the old way of having a single big linkcmd. You can change this for your new BSP. New ports/BSPs should definitely use a shared linkcmds.base (see ARM). Use "riscv-rtems4.12-ld --verbose" to get the default linker script. -- 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
RTEMS 4.12 tool chain update
Hello, I updated the tool chain (RSB) to use the latest Newlib snapshot with patches to move some POSIX header files to Newlib: https://devel.rtems.org/ticket/2833 The legacy network stack and the libbsd (I have to update it tomorrow) use now the same standard header files provided by Newlib. This tool chain update is a preparation step for the RTEMS 4.12 release. Now is a good time to test your favourite BSP. -- 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: Need help in building newlib
On Wed, Jun 7, 2017 at 5:30 AM, Sebastian Huber wrote: > Hello Aditya Upadhyay, > > please don't send me e-mails directly. Use the devel@rtems.org mailing list > instead. > > > On 07/06/17 11:21, aditya upadhyay wrote: >> >> Hello Sebastian Huber, >> >> I am Aditya Upadhyay, selected in GSoC 2017, for RTEMS organization. My >> project is POSIX Compliance. I have to work on newlib where i have to port >> the code of some functions and have to add some header file from RTEMS. I >> have implemented inttypes.h and its related methods in rtems. > > > There is already an inttypes.h in Newlib. Please fix this if something is > missing. Please don't write code on your own if there exists already an > implementation in FreeBSD, OpenBSD, NetBSD or bionic for this. > +1 Aditya, pllease audit what is already there. >> Now i want to port it to the newlib. But i have no idea how to port it to >> the newlib. Even i have tried to build newlib using this, described here : >> https://sourceware.org/newlib/ >> but i am not able to build it correctly. Is there any changes to do while >> executing this command- >> >> ../newlib-2.2.0/configure --host=sun4 --target=m68k-aout >> >> Here target should be sparc-rtems4.12 and what should be the host ? >> I need initial help. Once i will get the things clear, i will move ahead >> to work. >> Any help will be greatly appreciable and much helpful for me. > > > You can build the tool chain with the RSB (I guess this was already a part > of the GSoC preparation). It has reporting features to show you exactly the > commands used to produce the tool chain. You can then build it on your own > using these commands. > > Please use a Git clone of Newlib for this kind of work. > I gave instructions on how to do this in IRC last week. If you have struggled with that approach, please ask for more direction. It is straightforward to build a modified newlib using the RSB and local patches as described in the RSB documentation. > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V interrupts
2017-06-07 14:44 GMT+03:00 Sebastian Huber : > On 06/06/17 18:58, Hesham Almatary wrote: > > Originally RTEMS had a one big linkcmd for each platform, which >> defines linker symbols (used in C code) and required sections. This >> has been improved with current BSPs (like ARM-based ones), by >> splitting up shared linkcmd parts (linkcmd base) and BSP specific ones >> that include the shared one. riscv_generic, given that it's old, >> follows the old way of having a single big linkcmd. You can change >> this for your new BSP. >> > > New ports/BSPs should definitely use a shared linkcmds.base (see ARM). Use > "riscv-rtems4.12-ld --verbose" to get the default linker script. Ok. Now I have a problem: https://github.com/embeddedden/rtems-riscv/blob/hifive1/c/src/lib/libbsp/riscv32/hifive1/start/start.S#L117 When I step to that line, gdb hangs with a message: (gdb) step Note: automatically using hardware breakpoints for read-only addresses. Does somebody know what can be done here? Also, I don't like my initial linker file: https://github.com/embeddedden/rtems-riscv/blob/hifive1/c/src/lib/libbsp/riscv32/hifive1/startup/linkcmds Critique is very appreciated. -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V interrupts
On Wed, Jun 7, 2017 at 12:26 PM, Denis Obrezkov wrote: > 2017-06-07 14:44 GMT+03:00 Sebastian Huber > : >> >> On 06/06/17 18:58, Hesham Almatary wrote: >> >>> Originally RTEMS had a one big linkcmd for each platform, which >>> defines linker symbols (used in C code) and required sections. This >>> has been improved with current BSPs (like ARM-based ones), by >>> splitting up shared linkcmd parts (linkcmd base) and BSP specific ones >>> that include the shared one. riscv_generic, given that it's old, >>> follows the old way of having a single big linkcmd. You can change >>> this for your new BSP. >> >> >> New ports/BSPs should definitely use a shared linkcmds.base (see ARM). Use >> "riscv-rtems4.12-ld --verbose" to get the default linker script. > > Ok. > > Now I have a problem: > https://github.com/embeddedden/rtems-riscv/blob/hifive1/c/src/lib/libbsp/riscv32/hifive1/start/start.S#L117 > When I step to that line, gdb hangs with a message: > (gdb) step > Note: automatically using hardware breakpoints for read-only addresses. > > Does somebody know what can be done here? > Check what is the value in s0 before the jr, and compare that with the symbol map / function addresses, which you can get with nm or objdump. (I usually use xxx-rtems4.xx-objdump -dA hello.exe > hello.txt and examine the text file.) > Also, I don't like my initial linker file: > https://github.com/embeddedden/rtems-riscv/blob/hifive1/c/src/lib/libbsp/riscv32/hifive1/startup/linkcmds > Critique is very appreciated. > I can't look at this yet except to reiterate that it is worth it to mimic the arm/sparc BSPs and use a linkcmds.base file and then specialize it for each individual BSP. > > -- > Regards, Denis Obrezkov > > ___ > 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: RISC-V interrupts
On Thu, Jun 8, 2017 at 2:26 AM, Denis Obrezkov wrote: > 2017-06-07 14:44 GMT+03:00 Sebastian Huber > : >> >> On 06/06/17 18:58, Hesham Almatary wrote: >> >>> Originally RTEMS had a one big linkcmd for each platform, which >>> defines linker symbols (used in C code) and required sections. This >>> has been improved with current BSPs (like ARM-based ones), by >>> splitting up shared linkcmd parts (linkcmd base) and BSP specific ones >>> that include the shared one. riscv_generic, given that it's old, >>> follows the old way of having a single big linkcmd. You can change >>> this for your new BSP. >> >> >> New ports/BSPs should definitely use a shared linkcmds.base (see ARM). Use >> "riscv-rtems4.12-ld --verbose" to get the default linker script. > > Ok. > > Now I have a problem: > https://github.com/embeddedden/rtems-riscv/blob/hifive1/c/src/lib/libbsp/riscv32/hifive1/start/start.S#L117 > When I step to that line, gdb hangs with a message: > (gdb) step > Note: automatically using hardware breakpoints for read-only addresses. > How do you run/attach simulator (and which one do you use)? Do GDB and the simulator support 0x2040 > addresses (where your text section is loaded to)? AFAIK, that's not the case. Spike's default machine only works with addresses >= 0x8000. You've to look up if Spike, Qemu [1] or GDB target sim model your board. [1] https://github.com/riscv/riscv-qemu > Does somebody know what can be done here? > > Also, I don't like my initial linker file: > https://github.com/embeddedden/rtems-riscv/blob/hifive1/c/src/lib/libbsp/riscv32/hifive1/startup/linkcmds > Critique is very appreciated. > > > -- > Regards, Denis Obrezkov -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-source-builder commit] Fix for GCC 4.9 while building with GCC 6+
On 07/06/2017 23:23, Sebastian Huber wrote: > +%patch add gcc -p1 > https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff_plain;f=gcc/cp/Make-lang.in;h=b09fb02bb4c0d16fc2c842bec4069c033897b5f2;hp=e98beb1e33e4bcc4943361c559ae71b7eb345346;hb=1e5f1089dec3af328fd03125d6778f666d0bd4e4;hpb=88375bb2ba8b9004a9924cdae894d7ff32972652 > +%hash sha512 > Make-lang.in-h-b09fb02bb4c0d16fc2c842bec4069c033897b5f2-hp-e98beb1e33e4bcc4943361c559ae71b7eb345346-hb-1e5f1089dec3af328fd03125d6778f666d0bd4e4-hpb-88375bb2ba8b9004a9924cdae894d7ff32972652 > This file name is 188 characters in length. While it should not be a problem for other reasons it is starting to reaching the limit of the Windows Win32 API maximum file length. The following ticket comment provides more details: https://devel.rtems.org/ticket/2992#comment:1 I think the --rsb-file option and the short hash would work, for example Make-lang.in-h-b09fb02bb4c0 and we can avoid any issues on Windows. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-source-builder commit] Fix for GCC 4.9 while building with GCC 6+
On 08/06/17 00:33, Chris Johns wrote: On 07/06/2017 23:23, Sebastian Huber wrote: +%patch add gcc -p1 https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff_plain;f=gcc/cp/Make-lang.in;h=b09fb02bb4c0d16fc2c842bec4069c033897b5f2;hp=e98beb1e33e4bcc4943361c559ae71b7eb345346;hb=1e5f1089dec3af328fd03125d6778f666d0bd4e4;hpb=88375bb2ba8b9004a9924cdae894d7ff32972652 +%hash sha512 Make-lang.in-h-b09fb02bb4c0d16fc2c842bec4069c033897b5f2-hp-e98beb1e33e4bcc4943361c559ae71b7eb345346-hb-1e5f1089dec3af328fd03125d6778f666d0bd4e4-hpb-88375bb2ba8b9004a9924cdae894d7ff32972652 This file name is 188 characters in length. While it should not be a problem for other reasons it is starting to reaching the limit of the Windows Win32 API maximum file length. The following ticket comment provides more details: https://devel.rtems.org/ticket/2992#comment:1 I think the --rsb-file option and the short hash would work, for example Make-lang.in-h-b09fb02bb4c0 and we can avoid any issues on Windows. Something like this https://git.rtems.org/rtems-source-builder/commit/?id=2c13f00bf2d26ee50f5b49aa7ee6f05a6cce90c7 ? -- 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
[PATCH] sb: Restrict file name length
---
source-builder/sb/download.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/source-builder/sb/download.py b/source-builder/sb/download.py
index dd7880d..984bbaa 100644
--- a/source-builder/sb/download.py
+++ b/source-builder/sb/download.py
@@ -184,6 +184,9 @@ def _http_parser(source, pathkey, config, opts):
# Wipe out everything special in the file name.
#
source['file'] = re.sub(r'[^a-zA-Z0-9.\-]+', '-', source['file'])
+max_file_len = 127
+if len(source['file']) > max_file_len:
+raise error.general('file name length is greater than %i (maybe
use --rsb-file=FILE option): %s' % (max_file_len, source['file']))
#
# Check local path
#
--
2.12.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-source-builder commit] Fix for GCC 4.9 while building with GCC 6+
On 08/06/2017 15:11, Sebastian Huber wrote: > On 08/06/17 00:33, Chris Johns wrote: > >> On 07/06/2017 23:23, Sebastian Huber wrote: >>> +%patch add gcc -p1 >>> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff_plain;f=gcc/cp/Make-lang.in;h=b09fb02bb4c0d16fc2c842bec4069c033897b5f2;hp=e98beb1e33e4bcc4943361c559ae71b7eb345346;hb=1e5f1089dec3af328fd03125d6778f666d0bd4e4;hpb=88375bb2ba8b9004a9924cdae894d7ff32972652 >>> >>> +%hash sha512 >>> Make-lang.in-h-b09fb02bb4c0d16fc2c842bec4069c033897b5f2-hp-e98beb1e33e4bcc4943361c559ae71b7eb345346-hb-1e5f1089dec3af328fd03125d6778f666d0bd4e4-hpb-88375bb2ba8b9004a9924cdae894d7ff32972652 >>> >> This file name is 188 characters in length. While it should not be a problem >> for >> other reasons it is starting to reaching the limit of the Windows Win32 API >> maximum file length. The following ticket comment provides more details: >> >> https://devel.rtems.org/ticket/2992#comment:1 >> >> I think the --rsb-file option and the short hash would work, for example >> Make-lang.in-h-b09fb02bb4c0 and we can avoid any issues on Windows. > > Something like this > > https://git.rtems.org/rtems-source-builder/commit/?id=2c13f00bf2d26ee50f5b49aa7ee6f05a6cce90c7 > Yes and thanks. I think the file names may have worked but it would have depended on the path were the user starts. FYI GNU's as fails in a gcc build if the path is exceeded. I am currently working to remove any issues in the RSB and to get 4.11 stable. I am not sure if this is worth fixing as a Window 10 build is now available that turns this limit off. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sb: Restrict file name length
On 08/06/2017 15:22, Sebastian Huber wrote:
> ---
> source-builder/sb/download.py | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/source-builder/sb/download.py b/source-builder/sb/download.py
> index dd7880d..984bbaa 100644
> --- a/source-builder/sb/download.py
> +++ b/source-builder/sb/download.py
> @@ -184,6 +184,9 @@ def _http_parser(source, pathkey, config, opts):
> # Wipe out everything special in the file name.
> #
> source['file'] = re.sub(r'[^a-zA-Z0-9.\-]+', '-', source['file'])
> +max_file_len = 127
> +if len(source['file']) > max_file_len:
> +raise error.general('file name length is greater than %i (maybe
> use --rsb-file=FILE option): %s' % (max_file_len, source['file']))
Good idea.
Can we keep close(ish) to 80 columns?
raise error.general('name longer than %i (use --rsb-file=FILE): %s' % \
(max_file_len, source['file']))
?
Please push when ready.
Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-source-builder commit] sb: Create hopefully more valid file names
On 07/06/2017 23:23, Sebastian Huber wrote:
> @@ -180,12 +181,9 @@ def _http_parser(source, pathkey, config, opts):
> raise error.general('gitweb.cgi path missing p or h: %s' %
> (url))
> source['file'] = '%s-%s.patch' % (p, h)
> #
> -# Check the source file name for any extra request query data and
> remove if
> -# found. Some hosts do not like file names containing them.
> +# Wipe out everything special in the file name.
> #
> -if '?' in source['file']:
> -qmark = source['file'].find('?')
> -source['file'] = source['file'][:qmark]
> +source['file'] = re.sub(r'[^a-zA-Z0-9.\-]+', '-', source['file'])
I back ported this file back to 4.11 (see #3033) and this change has broken:
https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-automake-1.12.6-1.cfg?h=4.11#n18
The change in this patch means by default files names will be unique for
different URLs which is nice and I suppose it is just a matter of getting the
hashes to match.
I think I will merge the difference for the 4.11 branch.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
