On 3/08/2016 5:00 PM, Christian Mauderer wrote: > Am 03.08.2016 um 08:46 schrieb Chris Johns: >> On 03/08/2016 16:15, Christian Mauderer wrote: >>> Basically it boils down to the following: Currently I use an >>> __attribute__ on every variable that has to be initialized. That makes >>> updates a little more difficult because we would have to look out for >>> changed variables. In addition it is difficult for function static >>> variables. >> >> Ok, this makes sense. >> >>> A solution that would be simpler to maintain would be to manipulate the >>> object file. I would use objcopy to rename all sections with initialized >>> variables to put them into the linker set. This would be a little less >>> obvious if you read only the c code but it would solve both problems >>> mentioned above. >> >> Having transparent source is more important. > > If you mean by "transparent" that it is less changed from FreeBSD then I > agree. >
Yes this is what I mean. Source we take from FreeBSD with no changes is transparent. As we add changes the opacity level increases. I have added reporting to freebsd-to-rtems.py to provide us with a metric we can use to monitor this. > If you mean it should be more obvious where the section comes from > (simpler to read - more transparent to the reader) I would not. The > method with adding an attribute to every variable involves a lot of > manual work and therefore is more likely to introduce bugs. I agree, being as close to the FreeBSD source is important. >> >>> But it makes it necessary that the build system adds >>> the object file manipulation step before it links the application. That >>> is the point where I'm currently stuck. >> >> Should I wait for this to happen before adding any new control logic to >> the build system? > > I think that my main problem is to understand enough of waf so I can add > the object file manipulation. As soon as I managed that I should be able > to adapt it to a new control logic too without too much effort. So feel > free to make the changes whenever you can fit them into your schedule. OK. I will then take a look when I can. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel