From brianh@swift.West.Sun.COM Thu Jun 30 16:02:58 1994 Date: Thu, 30 Jun 1994 16:03:02 -0700 From: brianh@swift.West.Sun.COM (Brian H.) To: psarc@Eng Subject: PSARC 1994/197, 1994/198 Content-Type: X-sun-attachment X-Lines: 125 Status: RO Content-Length: 3576 ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 3 X-Sun-Content-Length: 187 The only supplementary materials for these cases are the following summaries of all architecturally significant changes that have been made to commands and libraries for these two cases. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: cmds.psarc X-Sun-Charset: us-ascii X-Sun-Content-Lines: 62 X-Sun-Content-Length: 1772 Commands changed for PowerPC port: adb: looks the same to the user, but we have changed adb, kadb and dis to all use the same dis-assembly routines (common source, not common binary). the ABI folk have not yet settled on a scheme for unambiguously identifying the arguments to a routine so we currently have some heuristics for determining what the arguments are. These heuristics are code that was already platform-dependent. ld: libld.so: The Procedure Linkage Tables are initialized at run time rather than statically (at link time), so that section in the ELF is now of type SHT_NOBITS. The initialization of the PLT happens in ld.so.1 We have PLTs with arbitrarily many entries (unlike SPARC). This is achieved with a project private interface between ld and ld.so.1. libconv: PowerPC relocation types liblddbg: PowerPC relocation types dis: we are seeking some guidance on how to resolve some inconsistancies between the output syntax of dis and the input syntax for as - as well as traditional inconsistancies between dis, adb and kadb output format. these issues will be forwarded to psarc prior to Tue 7/5. loadkeys: works like the SPARC rather than like the x86. In addition, during this work we have discovered a few things that could be changed in our sources to make such jobs easier: (1) Alignment contraint #ifdefs #if _ALIGNMENT_REQUIRED malloc_ptr &= ~_MAX_ALIGNMENT_MASK; /* force #endif #if _ALIGNMENT_LONG > 1 long_ptr &= ~_LONG_ALIGNMENT_MASK; #endif 2) Better attention to #ifdef _NO_LONGLONG Some code is still saying things like long long ll; instead of the preferred long_long_t ll; The SPARC (and not the x86) was used as the starting point for all base ON commands. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: libs.psarc X-Sun-Charset: us-ascii X-Sun-Content-Lines: 39 X-Sun-Content-Length: 1115 Library changes for PowerPC: New additions in the PPC port, required to support varargs per psABI: __va_list_to_vec(va_list) convert va_list to execl args __var_arg(va_list, enum arg_type) return pointer to next arg (per ANSI varargs spec) typedef struct { unsigned long var_arg_usage_info; unsigned long *overflow_area; unsigned long *arg_save_area; } va_list[1]; These interfaces are PUBLIC, as required by the psABI and used by compilers to implement ANSI standard varargs handling. __iob[_NFILE] psABI defines _NFILE as 3 rtld changed to implement the run-time initialization of procedure linkage table entries (as described under the apps changes), and supporting a (project private) interface for an arbitrarily large PLT. the PPC kernel passes some additional information in the auxillary vector (instruction and data cache block sizes), and the run time loader uses these numbers to optimize flushing and forcing of cache block lines. All other changes have no architectural content, and we used the SPARC (rather than the x86) as the starting point. From tcm@tortola Thu Jun 30 17:30:27 1994 Date: Thu, 30 Jun 1994 17:30:32 +0800 From: tcm@tortola (Terrence M.) To: brianh@swift.West.Sun.COM, psarc@sac Subject: PSARC 1994/197, 1994/198 Cc: ild-dev@sunpro Content-Length: 506 X-Lines: 20 Status: RO > cmds.psarc: > > ld: libld.so: > We have PLTs with arbitrarily many entries (unlike > SPARC). This is achieved with a project private > interface between ld and ld.so.1. > libs.psarc: > > rtld > > changed to implement the run-time initialization of procedure > linkage table entries (as described under the apps changes), > and supporting a (project private) interface for an arbitrarily > large PLT. Since Sun produces two linkers, this interface can not be project private. Terry From tcm@tortola Thu Jun 30 18:30:51 1994 Date: Thu, 30 Jun 1994 18:30:57 +0800 From: tcm@tortola (Terrence M.) To: brianh@swift.West.Sun.COM Subject: Re: PSARC 1994/197, 1994/198 Cc: psarc@sac Content-Length: 816 X-Lines: 21 Status: RO > From brianh@swift.West.Sun.COM Thu Jun 30 17:51 PDT 1994 > Date: Thu, 30 Jun 1994 17:50:49 -0700 > From: brianh@swift.West.Sun.COM (Brian H.) > To: Terrence.M.@Eng > Subject: Re: PSARC 1994/197, 1994/198 > > This was Mark Kample's addition. Perhaps I (and he) do not properly > understand the definition of "project private". > > The bottom line is that it of zero interest to anyone other than the those > interesting in supporting ld and/or rtld. Sun produces TWO linkers, ld and ild. Ild is built by the group that is called (starting tomorrow) SunSoft Development Products, They are not part of the same project as rtld. Also an ISV (Pure) produces a third linker which they will probaly want to port to PowerPC. Thus linker/rtld interfaces need to be Public not project private. Terry From brianh@swift.West.Sun.COM Thu Jun 30 18:37:58 1994 Date: Thu, 30 Jun 1994 18:37:22 -0700 From: brianh@swift.West.Sun.COM (Brian H.) To: brianh@swift.West.Sun.COM, Terrence.M.@Eng Subject: Re: PSARC 1994/197, 1994/198 Cc: psarc@sac.Eng.Sun.COM Content-Length: 713 X-Lines: 12 Status: RO > Sun produces TWO linkers, ld and ild. Ild is built by the group that > is called (starting tomorrow) SunSoft Development Products, They are > not part of the same project as rtld. Also an ISV (Pure) produces a > third linker which they will probaly want to port to PowerPC. Thus > linker/rtld interfaces need to be Public not project private. News to me. No problem, just change the associated tag. The specifics of what is done in the run-time loader is "private" to the run-time loader. The only "public" stuff is where the PLT entries are and the fact that the PLT is in a NOBITS section. That *does* need to be public. Like I said I believe it is just not understanding how things are catagorized. From brianh@pongo.West.Sun.COM Tue Jul 5 09:04:20 1994 Date: Tue, 5 Jul 1994 09:04:17 +0800 From: brianh@pongo.West.Sun.COM (Brian H.) To: psarc@Eng Subject: Addiitional info for case 1994/197 (PowerPC commands) Content-Length: 788 X-Lines: 21 Status: RO Various issues for "dis" as promised. (I may find more stuff, but...) Offsets in hex as well as symbol+hex? 0x20000048: _start+0x0: .... Instructions in hex as well as decoded? 0x20000048: _start+0x0: 0x7c6d1b78 mr %r13,%r3 Branch offsets as relative, absolute, +- decimal/hex? 0x20021022: main+0x124: bne -0x84 Range of symbol association? Such as what is settable in adb by "$s" Non-PowerPC instructions Some instruction are available on various PowerPC chips that are not available on the defined PowerPC architectures. Currently flagged with (Non-PowerPC). Which decode for ambiguous instrctions? mr %r3,%r4 v. ori %r3,%r4,0 Pay attention to relocations? bl 0x0 v. bl 0x0 (relocation) Offsets from index registers? Hex, decimal? lwz %r3,0x14(%r30) v. lwz %r3,20(%r30) From jek3@jurassic Mon Jul 11 12:22:07 1994 Date: Mon, 11 Jul 1994 12:26:21 +0800 From: jek3@jurassic (Joseph Kowalski) To: psarc@Eng, brianh@pongo.West.Sun.COM Subject: Re: Addiitional info for case 1994/197 (PowerPC commands) Content-Length: 1887 X-Lines: 67 Status: RO > From brianh@pongo.West.Sun.COM Tue Jul 5 09:09 PDT 1994 > > Various issues for "dis" as promised. (I may find more stuff, but...) I wonder why the ARC asked for this, because I'm not sure what the ARC intends to do with it.... I would believe that whatever format is used for disassembler output, it is going to be Uncommitted *or* is there some intent to make it be more than that because of the willingness/desire of people to write adb scripts. Anyway, to me only issues of relevance to the ARC are: What is the commitment level of the disassembler output (and if it is Public, where is the spec)? Is there benefit in uniformity between ISAs (such as to make writing scripts more protable)? You need to indicate which form you are proposing. It isn't clear. Since SSS already ``voted'' on these, I doubt my *opinion* matters, but for the record: > Offsets in hex as well as symbol+hex? > 0x20000048: _start+0x0: .... Whatever sparc/i386 do. > Instructions in hex as well as decoded? > 0x20000048: _start+0x0: 0x7c6d1b78 mr %r13,%r3 Whatever sparc/i386 do. > Branch offsets as relative, absolute, +- decimal/hex? > 0x20021022: main+0x124: bne -0x84 Whatever sparc/i386 do. > Range of symbol association? > Such as what is settable in adb by "$s" Proposal? > Non-PowerPC instructions > Some instruction are available on various PowerPC chips that are > not available on the defined PowerPC architectures. Currently > flagged with (Non-PowerPC). Good idea! > Which decode for ambiguous instrctions? > mr %r3,%r4 v. ori %r3,%r4,0 Can you ``guess'' what the coder mostly did? I doubt it. No opinion here. > Pay attention to relocations? > bl 0x0 v. bl 0x0 (relocation) No opinion. > Offsets from index registers? Hex, decimal? > lwz %r3,0x14(%r30) v. lwz %r3,20(%r30) I personally like hex, but this is purely personal preference. - jek3 From tcm@tortola Wed Oct 5 11:12:42 1994 Date: Wed, 5 Oct 1994 11:13:06 -0700 From: tcm@tortola (Terrence M.) To: psarc@sac Subject: Opinion for 1994/197 - PowerPC commands Content-Length: 2159 X-Lines: 82 Status: RO sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: PowerPC Commands Submitted by: Brian H. File: psarc/1994/197/opinion.ms Date: July 6th, 1994. Committee: Terrence M., Bruce D., Robert H., Marke K., Yousef K., Joseph Kowalski, Bill Shannon, Glenn Skinner, Ran- gaswamy V.. 1. Summary This project proposes to port the Solaris commands to the PowerPC. 2. Decision & Precedence Information The proposal is approved conditional upon submission of documentation of addittions made to isa.h.. The deliverables may be included in a minor release. This project depends on completion of: 1993/685 PowerPC ABI 3. Opinion The basic proposal to make the commands work on the PowerPC with the minimum changes in behavior was accepted with lit- tle discusion. The committee was not concerned with details of disassembly format(s) (an uncommitted interface). The committee did request clarification of the proposed need to add alignment constraint definitions to isa.h but accepted the teams rational with the proviso that any exten- sions be documented and become a public interface. 4. Minority Opinion(s) None. psarc/1994/197 Copyright 1994 Sun Microsystems, Inc. - 2 - 5. Advisory Information This project has created a common package for doing code disassembly for use by dis and adb (and dbx). The committee advices that a project be created to extend this work to our other ISA's. 6. Appendices 6.1. Appendix A: Technical Changes Required 1. The project must provide documentation for changes to isa.h. 6.2. Appendix B: Technical Changes Advised 1. The team is requested to provide a description of areas that required significant changes in order to do the port. 6.3. Appendix C: Reference Material ** Reference Material listed here. ** psarc/1994/197 Copyright 1994 Sun Microsystems, Inc. From tcm@tortola Wed Oct 26 10:27:13 1994 Date: Wed, 26 Oct 1994 10:27:15 -0700 From: tcm@tortola (Terrence M.) To: sac-review@sac Subject: PSARC 1994/197 PowerPC Commands Content-Length: 2209 X-Lines: 84 Status: RO sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: PowerPC Commands Submitted by: Brian H. File: psarc/1994/197/opinion.ms Date: July 6th, 1994 Committee: Terrence M., Bruce D., Robert H. Mark K., Yousef K., Joseph Kowalski, Bill Shannon, Glenn Skinner, Ran- gaswamy V.. 1. Summary This project proposes to port the Solaris commands to the PowerPC. 2. Decision & Precedence Information The proposal is approved conditional upon submission of documentation of addittions made to isa.h.. The deliverables may be included in a minor release. This project depends on completion of: 1993/685 3. Opinion The basic proposal to make the commands work on the PowerPC with the minimum changes in behavior was accepted with lit- tle discusion. The committee was not concerned with details of disassembly format(s) (an Uncommitted interface). The committee did request clarification of the proposed need to add alignment constraint definitions to isa.h but accepted the team's rationale with the proviso that any extensions be documented and become a Public interface. 4. Minority Opinion(s) None. 5. Advisory Information This project has created a common package for doing code psarc/1994/197 Copyright 1994 Sun Microsystems, Inc. - 2 - disassembly for use by dis and adb (and dbx). The committee advises that a project be created to extend this work to our other ISAs. 6. Appendices 6.1. Appendix A: Technical Changes Required 1. The project must provide documentation for changes to isa.h. 6.2. Appendix B: Technical Changes Advised 1. The team is requested to provide a description of areas that required significant changes in order to do the port. 6.3. Appendix C: Reference Material 1. /shared/sac/PSARC/1994/179/materials/commands.changes 2. /shared/sac/PSARC/1994/materials/isa_def psarc/1994/197 Copyright 1994 Sun Microsystems, Inc. From jek3@jurassic Wed May 24 14:29:40 1995 Date: Wed, 24 May 1995 14:28:27 -0700 From: jek3@jurassic (Joseph Kowalski) To: ppc-sos-iteam@atlanta, stevez@West, brian.h.@West, billt@West Subject: __va_list_to_vec() (psarc/1994/197) Cc: abe@West, rose@jurassic, psarc@sac Content-Length: 2507 (Resend: distribution corrected) I need some help in figuring out what's going on with PPC. In and I find the following definitions (for ppc only): /* these library functions have been added for execl() */ void **__va_list_to_vec(va_list); void __va_vec_free(void **); The only reference I can find to them in the ARC cases is: 1994/197 PowerPC Commands Brian H. closed approved 7/6/94 Terrence M. What I find in the mail file (and only the mail file) is: Library changes for PowerPC: New additions in the PPC port, required to support varargs per psABI: __va_list_to_vec(va_list) convert va_list to execl args __var_arg(va_list, enum arg_type) return pointer to next arg (per ANSI varargs spec) typedef struct { unsigned long var_arg_usage_info; unsigned long *overflow_area; unsigned long *arg_save_area; } va_list[1]; These interfaces are PUBLIC, as required by the psABI and used by compilers to implement ANSI standard varargs handling. I think this is only in the mail file because the materials didn't get updated when this case merged with the library case and the opinion didn't get an interfaces section. The other two interfaces listed above are in the psABI case. This is where it gets interesting. The PPC psABI (Draft March 1995) doesn't seem to mention either __va_list_to_vec() or __va_vec_free(). Nothing mentions __va_vec_free(). There is no documentation on either of these. When I look at the implementation, I find that this has been implemented for all ISA's. I also can see no reason that this has to be a public interface; it seems to be just implementation to me. I need to know which way this needs to go: 1] If it's just implementation (as the leading underscores would lead me to believe), I just need to delete the prototypes from the headers. (The ARC case was never updated; as I said, I found this much only in the mail logs.) 2] If they are indeed Public, PPC only interfaces we need to have a serious definition (like a man page or a description in the ABI) and the ARC case cleaned up. Since the implementation is global, we need the "Why Public on PPC only question also to be resolved?" 3] If they are intended to be Public on all ISA's, we need action similar to the above. This has been filed as 1207558. - jek3 From jek3@jurassic Wed May 24 15:00:47 1995 Date: Wed, 24 May 1995 14:59:33 -0700 From: jek3@jurassic (Joseph Kowalski) To: ppc-sos-iteam@atlanta, stevez@West, brian.h.@West, billt@West, jek3@jurassic Subject: Re: __va_list_to_vec() (psarc/1994/197) Cc: abe@West, rose@jurassic, psarc@sac Content-Length: 491 We have the following two opinions (which agree): Private mail: > From: brianh@swift.West.Sun.COM (Brian H.) ... > It is my belief that __va_list_to_vec() and __va_vec_free() are libc > internal and should *not* be public. Update to the bug report: > From: jordan@pongo.West (Jordan Brown) ... > It is my understanding that these are merely implementation, that they are > used solely by execl(). As such they shouldn't be in the header files and > needn't be documented. - jek3 From roland.mainz@nrubsig.org Wed May 6 19:54:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n472sd2C008114 for ; Wed, 6 May 2009 19:54:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n472sXGC029298; Thu, 7 May 2009 03:54:38 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ900E0J6QXUH00@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 19:54:33 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ900BSP6QX2670@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 19:54:33 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n472lgI1023995; Thu, 07 May 2009 02:54:32 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-1721496; Thu, 07 May 2009 02:54:32 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-524814; Thu, 07 May 2009 02:54:32 +0000 (Z) Received: from mail-in-09.arcor-online.net ([151.189.21.49] [151.189.21.49]) by relay1i.sun.com with ESMTP id BT-MMP-5769081; Thu, 07 May 2009 02:54:32 +0000 (Z) Received: from mail-in-10-z2.arcor-online.net (mail-in-10-z2.arcor-online.net [151.189.8.27]) by mx.arcor.de (Postfix) with ESMTP id E20561AF2FA; Thu, 07 May 2009 04:16:49 +0200 (CEST) Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) by mail-in-10-z2.arcor-online.net (Postfix) with ESMTP id CA18723D2B5; Thu, 07 May 2009 04:16:49 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-212-156.pools.arcor-ip.net [94.219.212.156]) by mail-in-11.arcor-online.net (Postfix) with ESMTPS id 27B9EE38FE; Thu, 07 May 2009 04:16:48 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n472GkrR002190; Thu, 07 May 2009 04:16:47 +0200 (CEST) Date: Thu, 07 May 2009 04:16:46 +0200 From: Roland Mainz Subject: Requesting ARC cases 1993/685, 1994/188, 1994/196, 1994/197, 1994/302, 1995/077, 1995/082, 1995/153 Sender: gisburn@jupiterb48.nrubsig.org To: opensolaris-arc@opensolaris.org Cc: Bonnie Corwin , "PSARC-EXT@sun.com" , emerging-platforms-discuss@opensolaris.org Message-id: <4A02448E.1AC9B6BA@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-11.arcor-online.net 27B9EE38FE X-Antispam: No, score=0.0/5.0, scanned in 0.057sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ x_sac_archived: PSARC/1993/685 x_sac_archived: PSARC/1994/188 x_sac_archived: PSARC/1994/196 Status: RO Content-Length: 704 hi! ---- I'd like to request to open the following ARC cases for publish access: PSARC 1993/685 PowerPC_ABI PSARC 1994/188 Solaris Kernel for PowerPC PSARC 1994/196 PowerPC Header Files PSARC 1994/197 PowerPC Commands PSARC 1994/302 PowerPC_Booting PSARC 1995/077 processor_info(2) binding for PowerPC and future ISAs PSARC 1995/082 PowerPC sysconfig parameters PSARC 1995/153 PPC installboot We need this materials as template for a set of ARC casess to specify support for a new architecture/hardware platform... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)