On Wed, Nov 10, 1999 at 10:55:46AM -0500, Ian Lance Taylor wrote: > Those patches were from Kazumoto Kojima > <[EMAIL PROTECTED]>, and were intended to support dynamic > linking for MIPS GNU/Linux. It may be that we should not be > generating SHN_MIPS_TEXT and SHN_MIPS_DATA in output files. This may > be an Irix specific thing. I don't know. I just checked this in the blue books from AT&T. It defines SHN_MIPS_ACOMMON (0xff00), SHN_MIPS_SCOMMON (0xff03), SHN_MIPS_SUNDEFINED (0xff04). 0xff01 and 0xff02 are reserved values. I guess the blue books are equivalent to ABI version 1.0. The current MIPS ABI 3.0 then defines SHM_MIPS_TEXT as 0xff01 and SHM_MIPS_DATA as 0xff02 with the following explanation: Symbols defined relative to these two sections are only present after a program has been rewritten by the pixie code profiling program. Such rewritten programs are not ABI-compliant. Symbols defined relative to these sections will never occur in an ABI-compliant program. I cc this to the various Linux/MIPS mailing lists. A number of the people who did work on the MIPS ABI and it's implementations are reading there. Maybe somebody can bring more light into this, especially the reasons for this SHN_MIPS_* magic. Ralf
