Sorry. I didn't see that patch get committed this morning and didn't realize it addressed the issue. When you said, BSPs needed to use linkcmds.base and not cut and paste, I took that to mean you hadn't touched any other BSPs.
I will try to test some on BSPs you didn't. Is the ticker addition just a temporary thing to get us through this testing phase? --joel On Tue, Dec 8, 2015 at 11:13 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Joel, > > before you start with wild guessing, please look at the patch: > > > https://git.rtems.org/rtems/commit/?id=b618d8cfc54f84d4ed03dc7b7fa510c872e6128a > > ----- Am 8. Dez 2015 um 16:45 schrieb Joel Sherrill <j...@rtems.org>: > > > > 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. > > > Why do you think BSPs are broken? If you look at my commit, then you will > see that I edited every linker command file by hand! Please note that there > are no changes for the ARM (except the GBA BSP, which is a removal > candidate if you ask me), SPARC and i386. They already use the linker sets > for the libbsd. > > You have defined maintained in your own way. > > > You can use other definitions and end up likely with the same set of BSPs. > > 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. > > > No, nothing must be migrated. In fact such a migration would be very > risky. You just need two section descriptions in the linker command file > (see user manual chapter). > > > 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. > > > I am not aware of any issues, except the dependency on the GNU linker. > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
