On 05/06/18 15:30, Sebastian Huber wrote:
Hello,
the RISC-V is a new architecture and the tool chain is still under
active development. For example one bug which blocks the RTEMS support
of the 64-bit RISC-V was fixed this week:
https://sourceware.org/bugzilla/show_bug.cgi?id=23244
The GDB
On 11/6/18 6:33 pm, Sebastian Huber wrote:
>
> Please review also this comment:
>
> https://devel.rtems.org/ticket/3448#comment:1
>
Done.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On 11/06/18 07:08, Sebastian Huber wrote:
On 08/06/18 07:54, Chris Johns wrote:
On 06/06/2018 19:57, Sebastian Huber wrote:
On 06/06/18 07:16, Sebastian Huber wrote:
We could use an unofficial mirror on Github, e.g.
https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3
On 08/06/18 07:54, Chris Johns wrote:
On 06/06/2018 19:57, Sebastian Huber wrote:
On 06/06/18 07:16, Sebastian Huber wrote:
We could use an unofficial mirror on Github, e.g.
https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f
My main concern with
On 06/06/2018 19:57, Sebastian Huber wrote:
> On 06/06/18 07:16, Sebastian Huber wrote:
>> We could use an unofficial mirror on Github, e.g.
>>
>> https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f
>>
>>
>> My main concern with using all these different
On 06/06/2018 19:37, Hesham Almatary wrote:
> If pulling from external GitHub repos (i.e. not GNU) is an option,
> then [1, 2] are very well-maintained and have any cutting-edge
> changes that are supposed to be merged with GNU repos. SiFive's SDK,
> FreeBSD and seL4 rely on riscv-tools and I alwa
On Thu, Jun 7, 2018 at 2:25 AM, Sebastian Huber
wrote:
> On 06/06/18 09:34, Chris Johns wrote:
>>>
>>> We could use an unofficial mirror on Github, e.g.
>>>
>>>
>>> https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f
>>>
>>>
>>> My main concern with usin
On 07/06/18 08:25, Sebastian Huber wrote:
On 06/06/18 09:34, Chris Johns wrote:
We could use an unofficial mirror on Github, e.g.
https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f
My main concern with using all these different download source
On 06/06/18 09:34, Chris Johns wrote:
We could use an unofficial mirror on Github, e.g.
https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f
My main concern with using all these different download sources is that this
will likely not work if we want t
On 06/06/18 07:16, Sebastian Huber wrote:
We could use an unofficial mirror on Github, e.g.
https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f
My main concern with using all these different download sources is
that this will likely not work if we
If pulling from external GitHub repos (i.e. not GNU) is an option,
then [1, 2] are very well-maintained and have any cutting-edge
changes that are supposed to be merged with GNU repos. SiFive's SDK,
FreeBSD and seL4 rely on riscv-tools and I always use it.
[1] https://github.com/riscv/riscv-gnu-
On 6/6/18 5:30 pm, Sebastian Huber wrote:
> On 06/06/18 07:16, Sebastian Huber wrote:
>>
>> We could use an unofficial mirror on Github, e.g.
>>
>> https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f
>>
>>
>> My main concern with using all these different
On 6/6/18 3:16 pm, Sebastian Huber wrote:
>
> The Git checkouts have the problem that you need an internet connection during
> the build (as far as I remember).
Yes you cannot take a repo offline like an archive.
I suppose I could change the way we handle git repos with an archive
configuration
On 06/06/18 07:16, Sebastian Huber wrote:
We could use an unofficial mirror on Github, e.g.
https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f
My main concern with using all these different download sources is
that this will likely not work if w
On 05/06/18 16:07, Gedare Bloom wrote:
On Tue, Jun 5, 2018 at 9:30 AM, Sebastian Huber
wrote:
Hello,
the RISC-V is a new architecture and the tool chain is still under active
development. For example one bug which blocks the RTEMS support of the
64-bit RISC-V was fixed this week:
https://sour
On Tue, Jun 5, 2018 at 9:07 AM, Gedare Bloom wrote:
> On Tue, Jun 5, 2018 at 9:30 AM, Sebastian Huber
> wrote:
> > Hello,
> >
> > the RISC-V is a new architecture and the tool chain is still under active
> > development. For example one bug which blocks the RTEMS support of the
> > 64-bit RISC-V
On Tue, Jun 5, 2018 at 9:30 AM, Sebastian Huber
wrote:
> Hello,
>
> the RISC-V is a new architecture and the tool chain is still under active
> development. For example one bug which blocks the RTEMS support of the
> 64-bit RISC-V was fixed this week:
>
> https://sourceware.org/bugzilla/show_bug.c
Hello,
the RISC-V is a new architecture and the tool chain is still under
active development. For example one bug which blocks the RTEMS support
of the 64-bit RISC-V was fixed this week:
https://sourceware.org/bugzilla/show_bug.cgi?id=23244
The GDB support is only available in the developmen
A second version of the GCC patch is attached. It has this problem:
https://gcc.gnu.org/ml/gcc/2018-05/msg00259.html
--
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...@
On Mon, May 28, 2018 at 10:57 AM, Sebastian Huber
wrote:
> On 28/05/18 11:51, Hesham Almatary wrote:
>>>
>>> I try currently a different direction. I use custom multilibs and changed
>>> the default cmodel to medany for the 64-bit variants. See attached patch.
>>>
I wonder if that issue/solution i
On 28/05/18 11:51, Hesham Almatary wrote:
I try currently a different direction. I use custom multilibs and changed
the default cmodel to medany for the 64-bit variants. See attached patch.
Thanks for sharing the patch, this solution is neat. We can get rid of
the arch alias hack.
No, we have
On Mon, May 28, 2018 at 10:38 AM, Sebastian Huber
wrote:
> On 28/05/18 11:14, Hesham Almatary wrote:
>>
>> On Mon, May 28, 2018 at 6:23 AM, Sebastian Huber
>> wrote:
>>>
>>> Hello,
>>>
>>> we currently have a riscv32-rtems* and riscv64-rtems* tool chain.
>>> However,
>>> the RISC-V GCC is a bi-a
On 28/05/18 11:14, Hesham Almatary wrote:
On Mon, May 28, 2018 at 6:23 AM, Sebastian Huber
wrote:
Hello,
we currently have a riscv32-rtems* and riscv64-rtems* tool chain. However,
the RISC-V GCC is a bi-arch compiler, e.g. we have
riscv32-rtems5-gcc --print-multi-lib
.;
rv32i/ilp32;@march=rv
On Mon, May 28, 2018 at 6:23 AM, Sebastian Huber
wrote:
> Hello,
>
> we currently have a riscv32-rtems* and riscv64-rtems* tool chain. However,
> the RISC-V GCC is a bi-arch compiler, e.g. we have
>
> riscv32-rtems5-gcc --print-multi-lib
> .;
> rv32i/ilp32;@march=rv32i@mabi=ilp32
> rv32im/ilp32;@m
On Mon, May 28, 2018 at 6:23 AM, Sebastian Huber
wrote:
> Hello,
>
> we currently have a riscv32-rtems* and riscv64-rtems* tool chain. However,
> the RISC-V GCC is a bi-arch compiler, e.g. we have
>
> riscv32-rtems5-gcc --print-multi-lib
> .;
> rv32i/ilp32;@march=rv32i@mabi=ilp32
> rv32im/ilp32;@m
On 28/05/18 07:23, Sebastian Huber wrote:
I suggest to merge the two tool chains into one riscv-rtems* variant.
Unfortunately, this is not easy to do. The "config.sub" script doesn't
recognize a "riscv" machine.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchh
Hello,
we currently have a riscv32-rtems* and riscv64-rtems* tool chain.
However, the RISC-V GCC is a bi-arch compiler, e.g. we have
riscv32-rtems5-gcc --print-multi-lib
.;
rv32i/ilp32;@march=rv32i@mabi=ilp32
rv32im/ilp32;@march=rv32im@mabi=ilp32
rv32iac/ilp32;@march=rv32iac@mabi=ilp32
rv32ima
27 matches
Mail list logo
