Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Chris Johns]

On 9/6/18 10:00 am, Joel Sherrill wrote:
> On Thu, Jun 7, 2018, 9:01 PM Chris Johns  > wrote:
> > and what
> > discussions we need to have to decide between the "bundled kernel.so 
> approach"
> > (the one implemented here) vs. the "FreeBSD loader.efi+hello.exe"
> approach. Let
> > me know!
> >
> 
> I do not think I can help too much here. I understand the loader.efi+exe
> solution and it should work because all RTEMS applications we have are
> statically linked (I am assuming it is here). I have not looked at the 
> details
> being used with the -fPIC and .so solution so I cannot comment. I do have 
> some
> concerns the relocatable exe might expose some dark corners and issues in 
> the
> host tools we have, for example how does GDB find the base address of the 
> image
> so you can debug it? and is this just working or is it really suppose to 
> work
> this way?
> 
> 
> All I can say is that with Deos/RTEMS, we use PIC on arm, PowerPC, and x86.

I would hope a solution like Deos did provide a seamless way to do this and I
would also hope they support you.

> We
> have spent a lot of time debugging with gdb attached to qemu.
How does GDB get the relocatable load address to map to the symbol table?

The libdl code supports the same protocol/design as NetBSD and other systems in
informing GDB about the address of loaded modules. There is a series of symbols
and tables maintained that GDB knows to examine to find the load addresses of
object files.

> I haven't seen any tools issues yet. 

Yet?  Once the path is settled it will be difficult to change so all I am asking
is the detail be checked and understood. RTEMS does not support shared libraries
the same way Linux or other Unix systems do. I do not understand enough of the
low level and the standards all this is based on to help decide.

An example of an issue where a relocatable kernel with an unknown load address
creates a problem is libdl. The testsuite uses the 2-pass approach (rtems-syms
--embed) which should be OK however the other approach where the symbol table is
not embedded and built on the host would fail. It is a small issue but it shows
how things can subtly break.

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

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Joel Sherrill]

On Thu, Jun 7, 2018, 9:01 PM Chris Johns  wrote:

> On 08/06/2018 01:50, Amaan Cheval wrote:
> >
> > Joel, Chris, I'd appreciate guidance on what I ought to work on next
>
> I would like to see the focus on the kernel context switcher, FPU support,
> and
> then interrupts so we have the basic drivers we need like a tick interrupt
> running.
>

+1

>
> This assumes the loader issues we have not resolved do not effect this
> work.
>
> > and what
> > discussions we need to have to decide between the "bundled kernel.so
> approach"
> > (the one implemented here) vs. the "FreeBSD loader.efi+hello.exe"
> approach. Let
> > me know!
> >
>
> I do not think I can help too much here. I understand the loader.efi+exe
> solution and it should work because all RTEMS applications we have are
> statically linked (I am assuming it is here). I have not looked at the
> details
> being used with the -fPIC and .so solution so I cannot comment. I do have
> some
> concerns the relocatable exe might expose some dark corners and issues in
> the
> host tools we have, for example how does GDB find the base address of the
> image
> so you can debug it? and is this just working or is it really suppose to
> work
> this way?
>

All I can say is that with Deos/RTEMS, we use PIC on arm, PowerPC, and x86.
We have spent a lot of time debugging with gdb attached to qemu. I haven't
seen any tools issues yet.



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

Re: [PATCH 3/6] shgen: Import from RTEMS

[Chris Johns]

On 9/6/18 9:48 am, Joel Sherrill wrote:
> On Fri, Jun 8, 2018 at 6:28 PM, Chris Johns  > wrote:
> 
> On 8/6/18 10:32 pm, Gedare Bloom wrote:
> > On Thu, Jun 7, 2018 at 10:19 PM, Chris Johns  > wrote:
> >> On 07/06/2018 16:11, Sebastian Huber wrote:
> >>> On 07/06/18 07:53, Chris Johns wrote:
>  On 07/06/2018 15:39, Sebastian Huber wrote:
> > Corresponding RTEMS commit is 
> 75933d5d25cd50f80162b7a0d2f66a5534e1763f.
> >
> > Update #3443.
> > ---
> >   misc/shgen/AUTHORS |   3 +
> >   misc/shgen/COPYING | 340
> +
> >   misc/shgen/TODO    |  13 ++
> >   misc/shgen/sci.c   | 177 
> >   misc/shgen/sci.h   |  11 ++
> >   misc/shgen/shgen.c | 114 ++
> >   misc/wscript       |   9 ++
> >   7 files changed, 667 insertions(+)
> >   create mode 100644 misc/shgen/AUTHORS
> >   create mode 100644 misc/shgen/COPYING
> >   create mode 100644 misc/shgen/TODO
> >   create mode 100644 misc/shgen/sci.c
> >   create mode 100644 misc/shgen/sci.h
> >   create mode 100644 misc/shgen/shgen.c
> >
> > diff --git a/misc/shgen/AUTHORS b/misc/shgen/AUTHORS
> > new file mode 100644
> > index 000..225c2fa
> > --- /dev/null
> > +++ b/misc/shgen/AUTHORS
> > @@ -0,0 +1,3 @@
> > +Ralf Corsepius (corse...@faw.uni-ulm.de 
> )
> > +    * Initial implementation
> > +    * generator for sci bitrate table
> > diff --git a/misc/shgen/COPYING b/misc/shgen/COPYING
> > new file mode 100644
> > index 000..8cc2ef7
> > --- /dev/null
> > +++ b/misc/shgen/COPYING
> > @@ -0,0 +1,340 @@
> > +
> > +            GNU GENERAL PUBLIC LICENSE
>  The RTEMS tools is almost clean of GPL code. There is a small piece 
> in the
>  rtemstoolkit I would to replace but I have not done that yet.
> >>>
> >>> The nios2gen is also GPL (the RTEMS GPL with linking exception). Is 
> this a
> >>> problem?
> >>
> >> We are moving to a BSD-2 license so I assumed this is part of that 
> change?
> >>
> >>> The GCC, GDB and Binutils are also GPL.
> >>
> >> They are not in this repo. It is about our repos and the compliance
> obligations
> >> users have with our code base.
> >>
> > No, I think  Sebastian's goal is to remove all host tools from the 
> rtems.git.
> >
> 
> Sorry, I was meaning the license and not the patch. Moving the tools is a 
> good
> idea but the RTEMS Tools is licensed BSD-2 or similar so moving GPL code 
> into
> that repo changes this.
> 
> 
> Is this tool actually used as part of building any SH BSP? I don't recall
> ever seeing a rule using it. I suspect it was used to generate headers
> initially manually and that was never part of the RTEMS build process.
> The tools was added just in case but never actually used.

Same, I have not seen it being used.

> IMO if that's the case, then we don't need it.

Agreed and if it turns out it is needed we can revisit this then.

> Do we even know what headers were generated by it?

Sorry, I do not know.

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

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Chris Johns]

On 9/6/18 2:39 am, Amaan Cheval wrote:
> On Fri, Jun 8, 2018 at 7:31 AM, Chris Johns  wrote:
>> On 08/06/2018 01:50, Amaan Cheval wrote:
>>>
>>> Joel, Chris, I'd appreciate guidance on what I ought to work on next
>>
>> I would like to see the focus on the kernel context switcher, FPU support, 
>> and
>> then interrupts so we have the basic drivers we need like a tick interrupt 
>> running.
>>
>> This assumes the loader issues we have not resolved do not effect this work.
>>
> 
> They do affect it to a certain extent - I'd be working semi-blind
> since without tying the loose ends required to boot, I wouldn't be
> able to test the implementations of the areas you mentioned. I'm not
> at that point yet, but I suspect I will be within a week or so, so the
> sooner we determine the approach required for booting, the better.

OK.

>>> and what
>>> discussions we need to have to decide between the "bundled kernel.so 
>>> approach"
>>> (the one implemented here) vs. the "FreeBSD loader.efi+hello.exe" approach. 
>>> Let
>>> me know!
>>>
>>
>> I do not think I can help too much here. I understand the loader.efi+exe
>> solution and it should work because all RTEMS applications we have are
>> statically linked (I am assuming it is here). I have not looked at the 
>> details
>> being used with the -fPIC and .so solution so I cannot comment. I do have 
>> some
>> concerns the relocatable exe might expose some dark corners and issues in the
>> host tools we have, for example how does GDB find the base address of the 
>> image
>> so you can debug it? and is this just working or is it really suppose to work
>> this way?
> 
> Well, these images won't simply _run_ through GDB, no - but here's
> some stuff that may be helpful to see:
> https://gist.github.com/AmaanC/4e1aaa2cbdda974b93c5a3e1eac5318a

Interesting and thanks. Is this with QEMU?

> One concern of yours was the unnecessary addition of the GOT/PLT.
> Thankfully, through options like -Bsymbolic, we can circumvent the
> GOT/PLT for all symbols which have already been resolved (as you'll
> see happens for "InitializeLib", "Print", "boot_card", etc. (boot_card
> because this is from my WIP version trying to get boot_card to work
> with this method too)).

The -Bsymbolic option is an example of my concern and stepping into a dark
corner. It could also be my lack of understanding. Yes it works but is that
always going to be the case? For example the GNU ld manual states:

 "This option is only meaningful on ELF platforms which support shared
  libraries and position independent executables."

and technically we do not support shared libraries so is this usage a normal use
case? I do not know. Also Oracle says the option is somewhat historic:

 https://docs.oracle.com/cd/E19957-01/806-0641/chapter4-16/index.html

> I'm definitely concerned, but having looked at it more, I can't find
> anything specific that would genuinely cause problems besides
> unresolved symbols - we could have a build-time check for them,
> though, failing the build when that's the case (-Wl,-z,defs does it).

If loader.efi+exe avoids this then it makes sense to me to do so. The less we
bend or stretch the more stable the support will be over time.

> So for next steps, I guess you'll be looking into how the use of -fPIC
> may affect us, and we can work on addressing those concerns, right? 

I do not know because I do not know risks.

> I
> personally preferred the static build approach too, since that way we
> can "plug" loaders in:
> - loader.efi for UEFI firmware
> - multiboot header + 32 to 64 bit mode code for Multiboot
>

Agreed.

> That's a slight oversimplification since (1) needs to be packaged on
> the filesystem with the static hello.exe

Yes this is a good point, then again this target is a bit different to other
targets. Users of PCs and similar hardware are use to boot loaders and managing
them plus handling the media needed. I do not think we will ever create a
bootable within an RTEMS build.

Could I install FreeBSD, load an RTEMS kernel onto the root directory and then
boot it with the standard FreeBSD loader.efi chain?

> and (2) needs to be linked in
> with it, but I think the build system retains more of its separations
> from the boot method this way (though I can't be sure given my
> relatively naive view of RTEMS + autotools).

I can help here if you need it.

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

Re: [PATCH 3/6] shgen: Import from RTEMS

[Joel Sherrill]

On Fri, Jun 8, 2018 at 6:28 PM, Chris Johns  wrote:

> On 8/6/18 10:32 pm, Gedare Bloom wrote:
> > On Thu, Jun 7, 2018 at 10:19 PM, Chris Johns  wrote:
> >> On 07/06/2018 16:11, Sebastian Huber wrote:
> >>> On 07/06/18 07:53, Chris Johns wrote:
>  On 07/06/2018 15:39, Sebastian Huber wrote:
> > Corresponding RTEMS commit is 75933d5d25cd50f80162b7a0d2f66a
> 5534e1763f.
> >
> > Update #3443.
> > ---
> >   misc/shgen/AUTHORS |   3 +
> >   misc/shgen/COPYING | 340 ++
> +++
> >   misc/shgen/TODO|  13 ++
> >   misc/shgen/sci.c   | 177 
> >   misc/shgen/sci.h   |  11 ++
> >   misc/shgen/shgen.c | 114 ++
> >   misc/wscript   |   9 ++
> >   7 files changed, 667 insertions(+)
> >   create mode 100644 misc/shgen/AUTHORS
> >   create mode 100644 misc/shgen/COPYING
> >   create mode 100644 misc/shgen/TODO
> >   create mode 100644 misc/shgen/sci.c
> >   create mode 100644 misc/shgen/sci.h
> >   create mode 100644 misc/shgen/shgen.c
> >
> > diff --git a/misc/shgen/AUTHORS b/misc/shgen/AUTHORS
> > new file mode 100644
> > index 000..225c2fa
> > --- /dev/null
> > +++ b/misc/shgen/AUTHORS
> > @@ -0,0 +1,3 @@
> > +Ralf Corsepius (corse...@faw.uni-ulm.de)
> > +* Initial implementation
> > +* generator for sci bitrate table
> > diff --git a/misc/shgen/COPYING b/misc/shgen/COPYING
> > new file mode 100644
> > index 000..8cc2ef7
> > --- /dev/null
> > +++ b/misc/shgen/COPYING
> > @@ -0,0 +1,340 @@
> > +
> > +GNU GENERAL PUBLIC LICENSE
>  The RTEMS tools is almost clean of GPL code. There is a small piece
> in the
>  rtemstoolkit I would to replace but I have not done that yet.
> >>>
> >>> The nios2gen is also GPL (the RTEMS GPL with linking exception). Is
> this a
> >>> problem?
> >>
> >> We are moving to a BSD-2 license so I assumed this is part of that
> change?
> >>
> >>> The GCC, GDB and Binutils are also GPL.
> >>
> >> They are not in this repo. It is about our repos and the compliance
> obligations
> >> users have with our code base.
> >>
> > No, I think  Sebastian's goal is to remove all host tools from the
> rtems.git.
> >
>
> Sorry, I was meaning the license and not the patch. Moving the tools is a
> good
> idea but the RTEMS Tools is licensed BSD-2 or similar so moving GPL code
> into
> that repo changes this.
>

Is this tool actually used as part of building any SH BSP? I don't recall
ever seeing a rule using it. I suspect it was used to generate headers
initially manually and that was never part of the RTEMS build process.
The tools was added just in case but never actually used.

IMO if that's the case, then we don't need it. Do we even know what
headers were generated by it?

--joel

>
> Chris
> ___
> 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 3/6] shgen: Import from RTEMS

[Chris Johns]

On 8/6/18 10:32 pm, Gedare Bloom wrote:
> On Thu, Jun 7, 2018 at 10:19 PM, Chris Johns  wrote:
>> On 07/06/2018 16:11, Sebastian Huber wrote:
>>> On 07/06/18 07:53, Chris Johns wrote:
 On 07/06/2018 15:39, Sebastian Huber wrote:
> Corresponding RTEMS commit is 75933d5d25cd50f80162b7a0d2f66a5534e1763f.
>
> Update #3443.
> ---
>   misc/shgen/AUTHORS |   3 +
>   misc/shgen/COPYING | 340 
> +
>   misc/shgen/TODO|  13 ++
>   misc/shgen/sci.c   | 177 
>   misc/shgen/sci.h   |  11 ++
>   misc/shgen/shgen.c | 114 ++
>   misc/wscript   |   9 ++
>   7 files changed, 667 insertions(+)
>   create mode 100644 misc/shgen/AUTHORS
>   create mode 100644 misc/shgen/COPYING
>   create mode 100644 misc/shgen/TODO
>   create mode 100644 misc/shgen/sci.c
>   create mode 100644 misc/shgen/sci.h
>   create mode 100644 misc/shgen/shgen.c
>
> diff --git a/misc/shgen/AUTHORS b/misc/shgen/AUTHORS
> new file mode 100644
> index 000..225c2fa
> --- /dev/null
> +++ b/misc/shgen/AUTHORS
> @@ -0,0 +1,3 @@
> +Ralf Corsepius (corse...@faw.uni-ulm.de)
> +* Initial implementation
> +* generator for sci bitrate table
> diff --git a/misc/shgen/COPYING b/misc/shgen/COPYING
> new file mode 100644
> index 000..8cc2ef7
> --- /dev/null
> +++ b/misc/shgen/COPYING
> @@ -0,0 +1,340 @@
> +
> +GNU GENERAL PUBLIC LICENSE
 The RTEMS tools is almost clean of GPL code. There is a small piece in the
 rtemstoolkit I would to replace but I have not done that yet.
>>>
>>> The nios2gen is also GPL (the RTEMS GPL with linking exception). Is this a
>>> problem?
>>
>> We are moving to a BSD-2 license so I assumed this is part of that change?
>>
>>> The GCC, GDB and Binutils are also GPL.
>>
>> They are not in this repo. It is about our repos and the compliance 
>> obligations
>> users have with our code base.
>>
> No, I think  Sebastian's goal is to remove all host tools from the rtems.git.
> 

Sorry, I was meaning the license and not the patch. Moving the tools is a good
idea but the RTEMS Tools is licensed BSD-2 or similar so moving GPL code into
that repo changes this.

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

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Amaan Cheval]

On Fri, Jun 8, 2018 at 7:31 AM, Chris Johns  wrote:
> On 08/06/2018 01:50, Amaan Cheval wrote:
>>
>> Joel, Chris, I'd appreciate guidance on what I ought to work on next
>
> I would like to see the focus on the kernel context switcher, FPU support, and
> then interrupts so we have the basic drivers we need like a tick interrupt 
> running.
>
> This assumes the loader issues we have not resolved do not effect this work.
>

They do affect it to a certain extent - I'd be working semi-blind
since without tying the loose ends required to boot, I wouldn't be
able to test the implementations of the areas you mentioned. I'm not
at that point yet, but I suspect I will be within a week or so, so the
sooner we determine the approach required for booting, the better.

>> and what
>> discussions we need to have to decide between the "bundled kernel.so 
>> approach"
>> (the one implemented here) vs. the "FreeBSD loader.efi+hello.exe" approach. 
>> Let
>> me know!
>>
>
> I do not think I can help too much here. I understand the loader.efi+exe
> solution and it should work because all RTEMS applications we have are
> statically linked (I am assuming it is here). I have not looked at the details
> being used with the -fPIC and .so solution so I cannot comment. I do have some
> concerns the relocatable exe might expose some dark corners and issues in the
> host tools we have, for example how does GDB find the base address of the 
> image
> so you can debug it? and is this just working or is it really suppose to work
> this way?

Well, these images won't simply _run_ through GDB, no - but here's
some stuff that may be helpful to see:
https://gist.github.com/AmaanC/4e1aaa2cbdda974b93c5a3e1eac5318a

One concern of yours was the unnecessary addition of the GOT/PLT.
Thankfully, through options like -Bsymbolic, we can circumvent the
GOT/PLT for all symbols which have already been resolved (as you'll
see happens for "InitializeLib", "Print", "boot_card", etc. (boot_card
because this is from my WIP version trying to get boot_card to work
with this method too)).

I'm definitely concerned, but having looked at it more, I can't find
anything specific that would genuinely cause problems besides
unresolved symbols - we could have a build-time check for them,
though, failing the build when that's the case (-Wl,-z,defs does it).

So for next steps, I guess you'll be looking into how the use of -fPIC
may affect us, and we can work on addressing those concerns, right? I
personally preferred the static build approach too, since that way we
can "plug" loaders in:
- loader.efi for UEFI firmware
- multiboot header + 32 to 64 bit mode code for Multiboot

That's a slight oversimplification since (1) needs to be packaged on
the filesystem with the static hello.exe and (2) needs to be linked in
with it, but I think the build system retains more of its separations
from the boot method this way (though I can't be sure given my
relatively naive view of RTEMS + autotools).

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

Re: [PATCH] Fix --show-commands.

[Chris Johns]

> On 8 Jun 2018, at 4:21 pm, Christian Mauderer 
>  wrote:
> 
>> Am 06.06.2018 um 09:48 schrieb Christian Mauderer:
>> In the current version of libbsd, if the --show-commands option is used,
>> the cwd is passed as a Nod3. Popen does not work with that. Therefore
>> create a string from cwd if it isn't already.
>> ---
>> rtems.py | 2 ++
>> 1 file changed, 2 insertions(+)
>> 
>> diff --git a/rtems.py b/rtems.py
>> index 6907709..a88c679 100644
>> --- a/rtems.py
>> +++ b/rtems.py
>> @@ -579,6 +579,8 @@ def output_command_line():
>> else:
>> cmdstr = ' '.join(cmd)
>> Logs.info('(%d) %s' % (len(cmdstr), cmdstr)) # here is the change
>> +if not isinstance(kw['cwd'], str):
>> +kw['cwd'] = str(kw['cwd'])
>> Logs.debug('runner_env: kw=%s' % kw)
>> try:
>> if self.logger:
>> 
> 
> Hello Chris,
> 
> do you see any problems with that patch?
> 

The patch is fine. I have not had time to merge it, I am still catching up.

> Please note that this is for your personal rtems_waf.git repo. So I
> can't check it in even if it would be acceptable. But if it is OK for
> you, I'll create and commit a patch for libbsd to use the new version as
> soon as this patch is commited.

Thanks. 

Chris

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

Re: [PATCH] Fix --show-commands.

[Gedare Bloom]

On Fri, Jun 8, 2018 at 2:21 AM, Christian Mauderer
 wrote:
> Am 06.06.2018 um 09:48 schrieb Christian Mauderer:
>> In the current version of libbsd, if the --show-commands option is used,
>> the cwd is passed as a Nod3. Popen does not work with that. Therefore
>> create a string from cwd if it isn't already.
>> ---
>>  rtems.py | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/rtems.py b/rtems.py
>> index 6907709..a88c679 100644
>> --- a/rtems.py
>> +++ b/rtems.py
>> @@ -579,6 +579,8 @@ def output_command_line():
>>  else:
>>  cmdstr = ' '.join(cmd)
>>  Logs.info('(%d) %s' % (len(cmdstr), cmdstr)) # here is the 
>> change
>> +if not isinstance(kw['cwd'], str):
>> +kw['cwd'] = str(kw['cwd'])
>>  Logs.debug('runner_env: kw=%s' % kw)
>>  try:
>>  if self.logger:
>>
>
> Hello Chris,
>
> do you see any problems with that patch?
>
> Please note that this is for your personal rtems_waf.git repo. So I
> can't check it in even if it would be acceptable. But if it is OK for
> you, I'll create and commit a patch for libbsd to use the new version as
> soon as this patch is commited.
>

rtems_waf should be migrated to the public set. it is now an integral
part of the infrastructure for waf builds of apps/libraries.

> Best regards
>
> Christian Mauderer
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> 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: configure/make with multiple jobs error?

[Gedare Bloom]

On Thu, Jun 7, 2018 at 10:04 PM, Chris Johns  wrote:
> On 08/06/2018 04:42, Gedare Bloom wrote:
>> OK, and I concur with your assessment. It worked a couple months ago.
>> I might try to bisect if I have time. I would bet something in our
>> scripts that changed during the source code reorg causes the problem.
>
> It should not be hard to find. Please raise a ticket so it is not forgotten.
>

https://devel.rtems.org/ticket/3450

Good idea. I may not get back to this for a bit.

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

Re: RISC-V tool chain

[Chris Johns]

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 download sources is that this
>> will likely not work if we want to use it in five or ten years due to URL
>> changes.
> 
> A proof of concept patch series is here:
> 
> https://lists.rtems.org/pipermail/devel/2018-June/021951.html
> 
> One problem with the using Binutils/GDB Git snapshots is that they share a
> repository.

Yes.

> I uses currently the Git mirror of some random user ("bminor"). I
> will try to set up a Binutils Git mirror for RTEMS. We don't need an automatic
> synchronization. We just have to do this for an RSB update.

What would be involved in making it automatic?

You could add cron a job on dispatch.rtems.org once a day. It would be a nice
server to have it close to current. :)

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