On Tue, Jun 5, 2018 at 9:07 AM, Gedare Bloom <ged...@rtems.org> wrote:
> On Tue, Jun 5, 2018 at 9:30 AM, Sebastian Huber > <sebastian.hu...@embedded-brains.de> 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 support is only available in the development branch of GDB. This > > makes it a bit difficult to use release versions of the tools. We used > > snapshots in the past, but the snapshots are removed from the FSF > download > > sites and mirrors after some time (e.g. half a year). This is not good if > > you want to bisect a bug and need to build the tool chain used for a > certain > > RTEMS version. > > > > What do you think about adding snapshots used by RSB to the RTEMS FTP > > server? > > > Hello Sebastian, > > I believe this has been discussed before although I can't find the > thread. I have concerns about the maintenance of snapshots. How many > target toolchains will we do this for, what frequency will snapshots > be taken, and how long will we preserve them? > > Is there a different low-cost technical solution that can be used > instead of a snapshot? For example, we can check-out a specific commit > from a repository: wouldn't it work well enough to identify such > commits and update them periodically instead of taking a full snapshot > of the tool sources? I believe this is how we have dealt with qemu in > the RSB, by picking one commit and sticking with it for awhile. > Using the git commit hash is better. If we have to stick with a snapshot going into a release, the release procedure grabs a tar image as I recall. --joel > > Gedare > > > -- > > 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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
