On Tue, Dec 8, 2015 at 9:09 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> On 08/12/15 16:03, Joel Sherrill wrote: > >> What BSPs/architectures have you tested? >> > > I temporarily moved the splinkersets01 test to the samples/ticker and > tested that all BSPs build and link this test. > > I executed the splinkersets01 test on sis, psim and > arm_realview_pbx_a9_qemu. > > >> Is this something that breaks on a per BSP basis? or per architecture >> basis? >> I am assuming that since it is linker based, each BSP could have broken >> linkcmds. >> Is that right? >> > > It breaks on a per linker command file basis. Since all the maintained > BSPs use a linkercmds.base, which shouldn't be a big issue. > > That means a LOT of the BSPs are broken. You have defined maintained in your own way. There are only a handful of architectures with linkcmds.base in them: ./or1k/shared/startup/linkcmds.base ./arm/shared/startup/linkcmds.base ./m68k/shared/startup/linkcmds.base ./powerpc/tqm8xx/startup/linkcmds.base ./powerpc/gen5200/startup/linkcmds.base ./powerpc/shared/startup/linkcmds.base ./sparc/shared/startup/linkcmds.base I am not sure how many BSPs within arm, m68k, or powerpc actually use the linkcmds.base. By my count, 13 of 94 BSP families have linkcmds.base. > For requirements on the linker command file, see new chapter in user > manual. However BSPs should not deal with this in copy and paste linker > command files and instead use a linkercmds.base file. > > So 85% of the BSP families don't use linkcmds.base and by the above statement, they must immediately be migrated to linkcmds.base. Unless you have a plan to address this problem, I am on the side of rejecting the part of this patch that changes the initialization. And the issue must be addressed before this can be merged. > > -- > 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
