From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: ian@zembu.com Cc: rth@cygnus.com, binutils@sourceware.cygnus.com Subject: Re: Patches for IRIX6 N32-ABI ld Date: Thu, 01 Jul 1999 00:00:00 -0000 Message-id: <19990626140924Q.mitchell@codesourcery.com> References: <19990626192703.9669.qmail@daffy.airs.com> <19990626134622L.mitchell@codesourcery.com> <19990626204616.9890.qmail@daffy.airs.com> <19990626204616.9890.qmail@daffy.airs.com> X-SW-Source: 1999-q2/msg00360.html >>>>> "Ian" == Ian Lance Taylor writes: Ian> I'm not sure why you want to bother, probably because I Ian> haven't seen the rest of your patches. Ian> Why not have two macros, one for general SGI compatibility, Ian> namely the existing SGI_COMPAT, and one new one you can use Ian> to check just which sort of SGI compatibility you want for a Ian> particular BFD? Your suggestion is clearly equally expressive, so it's not like something can be done way and not the other. So, if you insist on doing things your way, it's not like we'll lose anything. I assumed this to be non-controversial, and used things like `SGI_COMPAT (abfd) == sct_irix6' throughout the rest of my patches. So, changing this will require a bunch of extra work for me. That's not a great argument, but it's accurate. Also, "general SGI compatibility" is not a very well-defined notion. The whole reason this patch is necessary is that SGI_COMPAT turns on some behavior that isn't true in IRIX6; things have changed. They'll probably change again if there's ever an IRIX7, etc. So, saying `if (SGI_COMPAT (abfd))' is a maintenance headache anyhow. (It certainly was for me, at least, when working on the code.) My change makes it possible to gradually obsolete this usage. In particular, there's no need to change any existing code, but, on the other hand, it's easy to change conditions to express just what versions of IRIX things are appropriate for. I'm really not looking to get embroiled in line-edits, especially on the first set of diffs that add up to 3000 lines. So, I'll not argue the decision any further; I'll just abide by your next reply. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com