On Sat, Oct 31, 2015 at 03:02:07PM +0800, Andrew Pinski wrote: > On Fri, Oct 30, 2015 at 9:11 PM, Bernd Schmidt <bschm...@redhat.com> wrote: > > On 10/30/2015 01:47 PM, Richard Biener wrote: > >> > >> On Fri, Oct 30, 2015 at 1:28 PM, Bernd Schmidt <bschm...@redhat.com> > >> wrote: > >>>> > >>>> > >>>> it's not target independent code. Are you suggesting to add a config/ > >>>> to libobjc? IMHO for a not really mantained frontend / target lib > >>>> that's > >>>> an excessive requirement. > >>> > >>> > >>> > >>> If necessary, then yes that would be a better solution. > >>> > >>> Even just keeping the abstraction of the macro and putting definitions of > >>> it > >>> inside #ifdef at the top of the file would be an improvement over the > >>> submitted patch, but IMO still not really compatible with our standards. > >> > >> > >> I agree, that would make the source of the copy more obvious. > > > > > > If we go down that path, there's another minimum requirement - adjust the > > docs to say that the macro must be defined in two places. That's my main > > worry, someone creating a new port, completely oblivious that they'd have to > > modify library code for it to work. > > That happens already with respect to libffi anyways. libffi knows the > inter-working of how ABIs work and has many target specific assembly > code.
I think basically any library of sufficient size will end up having target specific code somewhere, and will require some amount of effort to port to new arches, and if it pokes at low level details it'll probably take even more. > If you look at libsanitizer, the code is even worse with all the > macros that need to be changed and I rather not go down that route > where we have processor specific #ifdefs in the code. I've never worked with libsanitizer, but #ifdef really isn't different from macros and a giant shell case on $target accept that has more indirection. libgcc uses a config/ and it is still some rather bad code, and don't get me started on the stuff people have stuffed into macros in gcc/config/. > Yes libobjc is mostly just works but going the route of libsanitizer > is just wrong and makes a really bad precedent of target libraries. That seems to be a conclusion without any real justification. It may well be true libsanitizer could be organized better, but just saying its "wrong" isn't very convincing ;) thanks Trev > Even libgomp has some target specific headers and is very short of the > number of headers/defines you need to change to it working (most of > the time none). > > Thanks, > Andrew > > > > > > > Bernd
