From sacadmin Thu Jan 11 13:35:13 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0BLZDf6018915 for ; Thu, 11 Jan 2007 13:35:13 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0BLZDXh018657 for ; Thu, 11 Jan 2007 13:35:13 -0800 (PST) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0BLZCe9023242 for ; Thu, 11 Jan 2007 14:35:12 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBQ003013KBA200@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 11 Jan 2007 14:35:12 -0700 (MST) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBQ00DX13YOHFZ4@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Thu, 11 Jan 2007 14:35:12 -0700 (MST) Date: Thu, 11 Jan 2007 14:37:14 -0700 From: Ali Bahrami Subject: PSARC/2007/026 ELF symbol sort sections Sender: Ali.Bahrami@Sun.COM To: psarc@sac.sfbay.sun.com Message-id: <45A6AE0A.30203@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) Status: RO Content-Length: 20953 I am sponsoring the following fasttrack for myself - timeout 01/18/07 ------------------------------------------------------------------------ Abstract ------- I plan to add two new ELF sections, named .SUNW_dynsymsort and .SUNW_dyntlssort, to all ELF files produced by ld(1) that have a .SUNW_ldynsym section. These new sections provide access to function and variable symbols, sorted by address. That data will ultimately be used by DTrace when operating in probe context, closing a hole in the way it currently maps addresses to symbols. These new sections add very little overhead to ELF files (well under 1% for all of ON), and are compatible with older versions of Solaris. The linker changes described here have been implemented and tested. The workspace can be found at: /net/rtld.central/export/home/ali/ws_6475344/onnv-clone Full nightly builds of ON (built on January 3rd) are available: /net/rtld.central/export/home/ali/ws_6475344/nightly_x86 /net/rtld.central/export/home/ali/ws_6475344/nightly_sparc These builds have been BFU'd on my desktop systems and are currently running: X86: rtld.central sparc: ldd.central Webrev is also available: http://jurassic.eng/~ab196087/webrev/6475344/index.html Background Information ---------------------- In probe context, DTrace needs to be able to map the virtual address of a variable or function within a process to an ELF symbol that describes it. Currently, the way this is done is that addresses are collected and periodically (every 2 seconds) passed from the kernel to user space, where libproc is used to do the work. This approach works, but has a significant shortcoming: When the target process exits, libproc cannot be used to process any addresses left in the buffer. Two seconds worth of data is significant, and useful information may be lost. To close this hole, the translation from address to symbol needs to be done in real time by the kernel. The symbols of interest exist within the contiguous symbol table made up from the adjacent .SUNW_ldynsym/.dynsym sections, so the raw data necessary to do an in-kernel translation is present. Unfortunately, this raw data is not in a form that allows an efficient search: - Symbols are not sorted by address, ruling out a binary search and forcing an O(n) brute force search instead. - There can be multiple symbols describing the same address, so even if you find one, you have to continue to the end, in case a better alternative should appear. For instance, a given function may have global and weak symbols, and we generally prefer to display the name of the weak version (no leading underscore). These related symbols are not necessarily found near each other. - In probe context, DTrace cannot allocate memory, and therefore cannot construct a more efficient representation of the symbol table (as is done in libproc, for instance). It has to work with what it can access in the existing address space. libproc overcomes these issues by building a list of symbols sorted by address. Such a sorted list can be used to implement a simple binary search that is fast (O(log N)), but requires allocation of dynamic memory and incurs time overhead to build. Building such a list in the kernel at runtime is not a viable option for DTrace. In order to do better than an O(n) search in the kernel, we need more support from the linker. Ideally, the linker would sort the symbol tables by address, allowing for a binary search. Unfortunately, this is not possible. There are rules and conventions that govern the order in which symbols appear, and these prevent such a reordering. A more detailed description of how ELF symbol tables are laid out can be found at http://blogs.sun.com/ali/entry/inside_elf_symbol_tables The main issue is that local and global symbols cannot be intermingled. Rather, the local symbols go at the top, and the globals follow. Sorting them by address would violate this constraint. Furthermore, the value of some symbol types do not correspond to addresses. It is not clear how one should sort them in such a list, and any direct search of the ELF symbol tables will require passing over them. For all of these reasons, sorting the existing symbol tables is not an option, and a different approach is required. Rather than sort the symbols themselves, we can construct a separate array of indices into the combined .SUNW_ldynsym/.dynsym symbol table. It is a simple matter to sort such an array of indices using the address of the symbols they reference as the sort key. Traversing such an array from beginning to end gives all of the desired symbols, in sorted order. The cost of such an array is small: - One additional indirection per symbol access. - One 32-bit integer (Elf32_Word, or ELF64_Word) per symbol, plus the minimal cost of an additional ELF section header. - The array need only hold the indices for interesting symbols, and not for every item in the symbol table. - The linker is constructed to handle this sort of task efficiently. This is the same approach that libproc uses. The difference is that libproc does it at runtime using dynamic memory. In this case, the linker will do it, and leave the resulting array in the process text segment along with the dynamic symbol tables, ready for for immediate use by DTrace. TLS (Thread Local Storage) and non-TLS (regular) symbols cannot be sorted together. The value of a non-TLS symbol is an addresses, while the value of a TLS symbol is an offset relative to the thread pointer (which is determined at runtime when a thread is created). The .SUNW_dynsymsort and .SUNW_dyntlssort Sections -------------------------------------------------- To address issues described above, ld will generate two new ELF sections for any sharable object or dynamic executable that also contains a .SUNW_ldynsym section: .SUNW_dynsymsort - An ELF section of type SHT_SUNW_SYMSORT, that contains indexes to non-TLS symbols in the combined .SUNW_ldynsym/.dynsym symbol table, sorted by address. Symbols that do not represent variables or functions are not included, and in the case of redundant global and weak symbols, only one (the weak one) is kept. .SUNW_dyntlssort - An ELF section of type SHT_SUNW_TLSSORT, that contains indexes to TLS symbols in the combined .SUNW_ldynsym/.dynsym symbol table, sorted by offset. This section is only produced if the object file contains TLS symbols. These arrays are directly usable with a binary search, to gain O(log N) symbol lookup in DTrace probe context, without the need to allocate memory at runtime. These new sections are allocable, meaning that they are part of the text segment that is mapped into the process address space. They are included in the signing computation carried out by /usr/bin/elfsign. Although the main motivation for this ELF section is to support DTrace, I have also modified the dladdr(3C) function to use it if it is present. It may also be of interest to debuggers. .SUNW_dynsymsort and .SUNW_dyntlssort sections require the presence of the .SUNW_ldynsym section. Therefore, they are only produced when .SUNW_ldynsym is present in the same file. Therefore, the ld -znoldynsym option, which suppresses .SUNW_ldynsym generation, also disables the generation of the sort sections. Minimal Size Increase --------------------- A key issue is whether or not the addition of .SUNW_dynsymsort and .SUNW_dyntlssort will cause an excessive increase in size. To answer this, I created a workspace containing the full ON usr tree, and then used a tar pipeline to make an identical copy. I built the first (baseline) workspace without modification, using the standard linker from Nevada build 50. I modified the second workspace to include new ELF sections, and then built it using the new linker. I found that the resulting proto area in the version with sort sections is 4 tenths of a percent (.4%) larger. So, the overall effect on the ON distribution is negligible. The overall impact is small. However, the impact on a specific library can be highly variable, as it depends on how many functions and variables are within. Libc is probably the most important such library. The version of /lib/libc.so.1 with sort sections is 1% larger, which is also quite modest. Furthermore, I believe this can be reduced somewhat by application of the new mapfile NODYNSORT keyword (described below). Symbol Selection Rules ---------------------- The linker uses the following rules, in the order shown, to select which symbols are referenced by the new sort sections. [1] Symbol must have a function or variable type: STT_FUNC, STT_OBJECT, STT_COMMON, or STT_TLS. [2] The following symbols are always included, if present: _DYNAMIC, _end, _fini, _GLOBAL_OFFSET_TABLE_, _init, _PROCEDURE_LINKAGE_TABLE_, _start. [3] If a global symbol and a weak symbol are found to reference the same item, the weak symbol is included, and the global is not. [4] The symbol must not be undefined. [5] The symbol must have non-zero size. These rules do a good job of filtering out compiler and linker generated boilerplate symbols, and selecting the symbols that are of interest to the user. However, there are two cases in which manual intervention might be necessary: - The rules did not select a needed special symbol (For instance, many special symbols have zero size). - Unwanted extra symbols are being selected. For example, some of our system libraries (particularly libc) define multiple symbols that reference the same address and have the same size (i.e. reference the same item). It would be ideal if only one of these were included in the sort sections, as some of these names represent implementation details with no user relevance. Two new mapfile keywords have been added to give the user control over these cases: DYNSORT - A symbol marked with the DYNSORT keyword is always included in a sort section, as long as the symbol type is one of the types allowed by selection rule [1] above. NODYNSORT - A symbol marked with the NODYNSORT keyword is always excluded from the sort section. In the case where a global and a weak symbol are found by the linker to reference the same item, the weak symbol is normally kept, as per rule [3] above. The mapfile keywords can be used to alter this choice. If the strong symbol is marked as DYNSORT, or the weak symbol is marked as NODYNSORT, then the weak symbol will be ignored and the strong symbol will be entered. To keep both, make them both DYNSORT. To eliminate both, make them both NODYNSORT. Observing Symbol Sort Sections with elfdump(1) ----------------------------------------------- The elfdump(1) command has a new command line option (-S) to display SHT_SUNW_symsort and SHT_SUNW_tlssort sections. If no command line options are used, elfdump produces a full dump, and the -S output is included. Elfdump uses the indexes in .SUNW_dynsymsort and .SUNW_dyntlssort to produce a symbol table listing in the sorted order. The index shown for each symbol is the index of that symbol relative to the start of the .SUNW_ldynsym. This includes symbols that are contained in the .dynsym. This is possible because the linker ensures that the data for .SUNW_ldynsym and .dynsym are adjacent, and can be treated as a single table. The following elfdump output is from a sharable library I constructed for testing purposes. The .SUNW_ldynsym, .dynsym, .SUNW_dynsymsort, and .SUNW_dyntlssort sections are all shown, allowing you to observe the interrelationships. [For this section, you will want to widen your terminal emulator window. I chose not to edit the elfdump output to fit in 80 characters, to ensure a faithful representation]: % elfdump -s -N.SUNW_ldynsym s.so Symbol Table Section: .SUNW_ldynsym index value size type bind oth ver shndx name [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF [1] 0x00000000 0x00000000 FILE LOCL D 0 ABS s.so [2] 0x00000820 0x00000041 FUNC LOCL H 0 .text fini1 [3] 0x00000870 0x00000041 FUNC LOCL H 0 .text fini2 [4] 0x000006e0 0x00000041 FUNC LOCL H 0 .text init1 [5] 0x00000730 0x00000041 FUNC LOCL H 0 .text init2 [6] 0x000008c0 0x0000008c FUNC LOCL H 0 .text call_kill [7] 0x00000780 0x00000041 FUNC LOCL H 0 .text pinit1 [8] 0x000007d0 0x00000041 FUNC LOCL H 0 .text pinit2 [9] 0x00000000 0x00000000 FILE LOCL D 0 ABS s.c [10] 0x00000950 0x0000009e FUNC LOCL D 0 .text bar % elfdump -s -N.dynsym s.so Symbol Table Section: .dynsym index value size type bind oth ver shndx name [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF [1] 0x00000660 0x00000000 OBJT GLOB D 1 .plt _PROCEDURE_LINKAGE_TABLE_ [2] 0x00000000 0x00000000 FUNC GLOB D 0 UNDEF getpid [3] 0x00014d04 0x00000004 OBJT GLOB D 1 .data autodata [4] 0x00018d10 0x00000000 OBJT GLOB D 1 .tdata _edata [5] 0x00000000 0x00000000 FUNC GLOB D 0 UNDEF kill [6] 0x00014b50 0x00000000 OBJT GLOB D 1 .got _GLOBAL_OFFSET_TABLE_ [7] 0x000006d0 0x00000001 FUNC GLOB D 1 .text autofunc [8] 0x00000000 0x00000000 FUNC GLOB D 0 UNDEF printf [9] 0x00014bbc 0x00000000 OBJT GLOB D 1 .dynamic _DYNAMIC [10] 0x000009f0 0x000000a7 FUNC GLOB D 2 .text _foo [11] 0x000009f0 0x000000a7 FUNC WEAK D 2 .text foo [12] 0x00018d10 0x00000000 OBJT GLOB D 1 .bss _end [13] 0x00004b50 0x00000000 OBJT GLOB D 1 .rodata1 _etext [14] 0x00000000 0x00000004 TLS GLOB D 2 .tdata tlsvar1 [15] 0x00000000 0x00000000 FUNC GLOB D 0 UNDEF malloc [16] 0x00000004 0x00000004 TLS GLOB D 2 .tdata tlsvar2 [17] 0x00000000 0x00000000 FUNC GLOB D 0 UNDEF printstack [18] 0x00000000 0x00000000 FUNC WEAK D 0 UNDEF ___tls_get_addr [19] 0x00000000 0x00000000 OBJT GLOB D 2 ABS SUNW1.1 % elfdump -S s.so Symbol Sort Section: .SUNW_dynsymsort (.SUNW_ldynsym / .dynsym) index value size type bind oth ver shndx name [12] 0x00000660 0x00000000 OBJT GLOB D 1 .plt _PROCEDURE_LINKAGE_TABLE_ [18] 0x000006d0 0x00000001 FUNC GLOB D 1 .text autofunc [4] 0x000006e0 0x00000041 FUNC LOCL H 0 .text init1 [5] 0x00000730 0x00000041 FUNC LOCL H 0 .text init2 [7] 0x00000780 0x00000041 FUNC LOCL H 0 .text pinit1 [8] 0x000007d0 0x00000041 FUNC LOCL H 0 .text pinit2 [2] 0x00000820 0x00000041 FUNC LOCL H 0 .text fini1 [3] 0x00000870 0x00000041 FUNC LOCL H 0 .text fini2 [6] 0x000008c0 0x0000008c FUNC LOCL H 0 .text call_kill [10] 0x00000950 0x0000009e FUNC LOCL D 0 .text bar [22] 0x000009f0 0x000000a7 FUNC WEAK D 2 .text foo [17] 0x00014b50 0x00000000 OBJT GLOB D 1 .got _GLOBAL_OFFSET_TABLE_ [20] 0x00014bbc 0x00000000 OBJT GLOB D 1 .dynamic _DYNAMIC [14] 0x00014d04 0x00000004 OBJT GLOB D 1 .data autodata [23] 0x00018d10 0x00000000 OBJT GLOB D 1 .bss _end Symbol Sort Section: .SUNW_dyntlssort (.SUNW_ldynsym / .dynsym) index value size type bind oth ver shndx name [25] 0x00000000 0x00000004 TLS GLOB D 2 .tdata tlsvar1 [27] 0x00000004 0x00000004 TLS GLOB D 2 .tdata tlsvar2 I would like to point out some things about the above output: - Symbols from .SUNW_ldynsym and .dynsym that do not represent functions or data are filtered out of the sort sections, leaving only interesting symbols with addresses. - foo is a weak symbol, tied to the global _foo. The WEAK version (non-underscored) is chosen for .SUNW_dynsymsort. The user will therefore see the name they expect and not a name that reflects internal implementation details (e.g. "read" rather than "_read"). - It is clear from the small integer values of the TLS symbols in .SUNW_dyntlssort that these are offsets, and not addresses. - The two sort sections do not contain the actual symbols. The display above is generated by elfdump, by using the indices in .SUNW_dynsymsort and .SUNW_dyntlssort to index the symbol tables. - Notice that the index of symbol foo is [22] in .SUNW_dynsymsort, but is [11] in .dynsym. The index in .SUNW_dynsymsort is relative to the start of .SUNW_ldynsym. In this case, the .SUNW_ldynsym section has 11 entries, which added to the offset of foo in .dynsym gives the [22] shown. Runtime Linker Access to Sort Sections -------------------------------------- When ld(1) generates .SUNW_dynsymsort and/or .SUNW_dyntlssort sections, it puts entries in the .dynamic section to enable the runtime linker (ld.so.1) to locate and use them: DT_SUNW_SORTENT - Size of a single element of a sort section of either type (SHT_SUNW_SYMSORT or SHT_SUNW_TLSSORT). DT_SUNW_SYMSORT - Address of the start of the .SUNW_dynsymsort section. DT_SUNW_SYMSORTSZ - Size of the .SUNW_dynsymsort section. DT_SUNW_TLSSORT - Address of the start of the .SUNW_dyntlssort section. DT_SUNW_TLSSORTSZ - Size of the .SUNW_dyntlssort section. The dladdr() function has been modified to take advantage of DT_SUNW_SYMSORT to perform an O(log N) search, when possible. When DT_SUNW_SYMSORT is not available, the old O(n) search is used. Backward Compatibility ---------------------- ELF is designed to allow the addition of new section types and sections. These new symbol sort sections are backwards compatible with older versions of Solaris. Although an older linker will not recognize these new items, it will still be able to use the files that contain them, to the same degree that would have been otherwise true. When an old linker encounters a a new symbol sort section, it will produce warning messages of the form: ld: warning: file libelf.so: section .SUNW_dynsymsort has invalid type 0x6ffffff1 ld: warning: file libelf.so: section .SUNW_dyntlssort has invalid type 0x6ffffff2 These warnings may be safely ignored. Next Steps ---------- (Note: The information in this section is not part of this ARC, but is included to help the reader see how the work described here fits into the bigger picture. Following the integration of this work, it will be necessary to modify the linker mapfiles for the executables and sharable objects in ON, adding DYNSORT and NODYNSORT keywords as necessary to eliminate duplicate entries in the sort sections. Although the duplicate symbols are essentially harmless, they waste space, and may lead to observability tools showing different (but equivalent) names for the same item. For example, consider the following from libc: [3579] 0x00040d7c 0x00000008 FUNC WEAK D 4 .text atomic_inc_8 [5026] 0x00040d7c 0x00000008 FUNC WEAK D 4 .text atomic_inc_uchar [4136] 0x00040d7c 0x00000008 FUNC GLOB D 36 .text _atomic_inc_8 [4561] 0x00040d7c 0x00000008 FUNC GLOB D 36 .text _atomic_inc_8_nv [2433] 0x00040d7c 0x00000008 FUNC GLOB D 36 .text _atomic_inc_uchar [3887] 0x00040d7c 0x00000008 FUNC WEAK D 4 .text atomic_inc_8_nv [3784] 0x00040d7c 0x00000008 FUNC WEAK D 4 .text atomic_inc_uchar_nv Only one of these needs to be in the sort section, but there is no good automatic way to know which. Cases like this must be managed via the mapfile. Once the ON mapfiles have been updated to clean up these duplicates, it is necessary to prevent new duplicates from being added. The solution to this is will be to add a test to the check_rtime script (/opt/onbld/bin/check_rtime) that is run as part of nightly builds. I intend to file a CR for the steps above, following the integration of the work described in this ARC, and to address the above issues. ------------------------------------------------------------------------ Release Binding: Patch/Micro SHT_SUNW_SYMSORT (.SUNW_dynsymsort): Committed SHT_SUNW_TLSSORT (.SUNW_dyntlssort): Committed Mapfile DYNSORT and NODYNSORT: Committed DT_SUNW_SORTENT: Committed DT_SUNW_SYMSORT: Committed DT_SUNW_SYMSORTSZ: Committed DT_SUNW_TLSSORT: Committed DT_SUNW_TLSSORTSZ: Committed elfdump -S Committed From sacadmin Thu Jan 11 14:23:07 2007 Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0BMN7Hr020787 for ; Thu, 11 Jan 2007 14:23:07 -0800 (PST) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id l0BMM1oN006425; Thu, 11 Jan 2007 14:22:01 -0800 (PST) Message-Id: <200701112222.l0BMM1oN006425@ivrel.sfbay.sun.com> Date: Thu, 11 Jan 2007 14:22:01 -0800 (PST) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: 2007/026 [ELF symbol sort sections] To: psarc@sac.sfbay.sun.com, Ali.Bahrami@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5oFWtWkvD44oAv4fRgkhhQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 692 Date: Thu, 11 Jan 2007 14:37:14 -0700 From: Ali Bahrami Subject: PSARC/2007/026 ELF symbol sort sections ... This is the same approach that libproc uses. The difference is that libproc does it at runtime using dynamic memory. In this case, the linker will do it, and leave the resulting array in the process text segment along with the dynamic symbol tables, ready for for immediate use by DTrace. Does this case propose to modify libproc to use these new sections if they're present (and thus avoid duplicating the work that the linker has already done)? I didn't see such a modification mentioned in the proposal. -- Glenn From sacadmin Thu Jan 11 15:00:45 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0BN0jBm021732 for ; Thu, 11 Jan 2007 15:00:45 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0BN0i0d000957 for ; Thu, 11 Jan 2007 15:00:44 -0800 (PST) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0BN0gOt026620 for ; Thu, 11 Jan 2007 16:00:44 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBQ000017EIK900@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 11 Jan 2007 16:00:42 -0700 (MST) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBQ004MQ7X6TLT7@mail-amer.sun.com>; Thu, 11 Jan 2007 16:00:42 -0700 (MST) Date: Thu, 11 Jan 2007 16:02:45 -0700 From: Ali Bahrami Subject: Re: 2007/026 [ELF symbol sort sections] In-reply-to: <200701112222.l0BMM1oN006425@ivrel.sfbay.sun.com> Sender: Ali.Bahrami@Sun.COM To: Glenn Skinner Cc: psarc@sac.sfbay.sun.com Message-id: <45A6C215.4010006@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200701112222.l0BMM1oN006425@ivrel.sfbay.sun.com> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) Status: RO Content-Length: 2442 Glenn Skinner wrote: > Date: Thu, 11 Jan 2007 14:37:14 -0700 > From: Ali Bahrami > Subject: PSARC/2007/026 ELF symbol sort sections > > ... > This is the same approach that libproc uses. The difference is > that libproc does it at runtime using dynamic memory. In this > case, the linker will do it, and leave the resulting array in the > process text segment along with the dynamic symbol tables, ready > for for immediate use by DTrace. > > Does this case propose to modify libproc to use these new sections if > they're present (and thus avoid duplicating the work that the linker > has already done)? I didn't see such a modification mentioned in the > proposal. > > -- Glenn > In principle, there is nothing to prevent us from doing this. However, it is not part of this case. I just did some work on libproc 6475315 libproc should take advantage of new .SUNW_ldynsym ELF sections and I came away thinking that the complexity this would introduce to libproc would not be worth it. Libproc doesn't have the same constraints that DTrace (for instance does). Allocating a little memory and doing a sort in that context is not a problem. These new sections would not be justified if it were not for the desire for DTrace to be able to do in-kernel lookups. The complicating issues are: - libproc uses two different sortings, one is by address, and the other is by name. The new .SUNW_dynsymsort section could be used for the by-addr case, but libproc would still have to build the other. As you might expect, building both is not twice as expensive as building one. - It will always be possible for a file to lack the .SUNW_dynsymsort section, so libproc will still have to be prepared to do things the old way. - If libproc uses .SUNW_dynsymsort for the by-addr case, and uses its own sorted array for the by-name case, then there will exist the possibility that a given address will not yield the same symbol when looked up in those two ways. (Some of our objects, particularly libc, have more than one symbol for a given address). This is not "wrong", since both answers are correct, but it could be confusing to the user. Given all of that, it seems better to leave libproc alone. This is something that could be done later if it becomes compelling. - Ali From sacadmin Fri Jan 12 02:38:34 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0CAcY4E007857 for ; Fri, 12 Jan 2007 02:38:34 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0CAcXa6000692 for ; Fri, 12 Jan 2007 02:38:34 -0800 (PST) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0CAcROl017182 for ; Fri, 12 Jan 2007 10:38:28 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBR00M014681600@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 12 Jan 2007 10:38:27 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBR005G5482HA00@d1-emea-10.sun.com> for psarc@sac.sfbay.sun.com; Fri, 12 Jan 2007 10:38:27 +0000 (GMT) Date: Fri, 12 Jan 2007 10:38:26 +0000 From: Darren J Moffat Subject: Re: PSARC/2007/026 ELF symbol sort sections In-reply-to: <45A6AE0A.30203@sun.com> Sender: Darren.Moffat@Sun.COM To: Ali Bahrami Cc: psarc@sac.sfbay.sun.com Message-id: <45A76522.9080804@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <45A6AE0A.30203@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061128) Status: RO Content-Length: 428 This looks great, and the scary thing is I think I understood almost all of it! Does this case include changing DTrace to use this or does that not happen until later ? I might have missed it in the text but what is the taxonomy of the new sections - I assume they would be Consolidation Private or Project Private with a contract to DTrace. Also the release binding - here I assume you wanted patch. -- Darren J Moffat From sacadmin Fri Jan 12 09:11:20 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0CHBJ4l013684 for ; Fri, 12 Jan 2007 09:11:19 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0CHBJlO014803 for ; Fri, 12 Jan 2007 09:11:19 -0800 (PST) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0CHBJE2016011 for ; Fri, 12 Jan 2007 10:11:19 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBR00J01M4BUX00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 12 Jan 2007 10:11:19 -0700 (MST) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBR00D27MEUHFJ5@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Fri, 12 Jan 2007 10:11:19 -0700 (MST) Date: Fri, 12 Jan 2007 10:13:21 -0700 From: Ali Bahrami Subject: Re: PSARC/2007/026 ELF symbol sort sections In-reply-to: <45A76522.9080804@Sun.COM> Sender: Ali.Bahrami@Sun.COM To: Darren J Moffat Cc: psarc@sac.sfbay.sun.com Message-id: <45A7C1B1.1090904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <45A6AE0A.30203@sun.com> <45A76522.9080804@Sun.COM> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) Status: RO Content-Length: 3435 Darren J Moffat wrote: > This looks great, and the scary thing is I think I understood almost all > of it! > > Does this case include changing DTrace to use this or does that not > happen until later ? > > I might have missed it in the text but what is the taxonomy of the new > sections - I assume they would be Consolidation Private or Project > Private with a contract to DTrace. Also the release binding - here I > assume you wanted patch. > > -- > Darren J Moffat I put the taxonomy and binding at the end of the initial message. We (linkers group) see no need to restrict it --- it's all public. >Release Binding: Patch/Micro > > SHT_SUNW_SYMSORT (.SUNW_dynsymsort): Committed > SHT_SUNW_TLSSORT (.SUNW_dyntlssort): Committed > Mapfile DYNSORT and NODYNSORT: Committed > DT_SUNW_SORTENT: Committed > DT_SUNW_SYMSORT: Committed > DT_SUNW_SYMSORTSZ: Committed > DT_SUNW_TLSSORT: Committed > DT_SUNW_TLSSORTSZ: Committed > elfdump -S Committed This case does not include changing DTrace. It is a necessary precondition to doing so, but the DTrace work will be done in a separate project. Although it is not part of this ARC, let me quickly sketch out where I believe we are heading. The remaining missing piece in solving the DTrace problem is how to communicate all of this information about symbol tables, string tables, and sort sections, to the DTrace probe context code that needs it. Currently, that information resides in userland, in the runtime linker. I believe that the right place to solve this will be as part of: 6502792 Same dynamic libraries should be mapped at the same virtual addresses in different processes That CR contains a proposal for a new ELF-aware system call for mapping ELF files. The runtime linker will use this new mmapfd() system call instead of mmap() to map ELF objects. There are many reasons why this would be a big win, both for some of our high end systems, and for the linker: - It lets new hardware take advantage of unique abilities in a timely fashion, and under the control of the people who actually know what is needed. - Those special hacks disappear, along with any other special kernel support, when that hardware is no longer supported, so we don't end up carrying no longer used cruft around in our code. mmapfd() would be used for all ELF section mapping, with the exception of the mappings done by exec(). One side effect of this approach is that the kernel will have explicit knowledge of all ELF mappings in a given process, something that isn't true today (we use mmap() --- the kernel doesn't know what the data it is mmapping means). This explicit knowledge makes mmapfd() the ideal place for the kernel, while it is mapping the file, to harvest and retain the necessary information on where the ELF symbol, string table, and sort sections are. Given a data structure (AVL tree?) that lets DTrace quickly get to this information, the rest of the implementation (a binary search function) will be easy. The other way to do this is for the runtime linker to build that data structure and somehow communicate it to the kernel. I prefer the mmapfd() idea because it eliminates the need for awkward coordination between the kernel and userland. - Ali From sacadmin Fri Jan 12 12:29:17 2007 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0CKTGIc019374 for ; Fri, 12 Jan 2007 12:29:17 -0800 (PST) Received: from [129.148.226.12] (sr1-unsh01-02.East.Sun.COM [129.148.226.12]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0CKTEt6018201; Fri, 12 Jan 2007 15:29:15 -0500 (EST) Message-ID: <45A7EF9A.4090900@sun.com> Date: Fri, 12 Jan 2007 15:29:14 -0500 From: Brian Utterback User-Agent: Thunderbird 2.0b1 (X11/20070109) MIME-Version: 1.0 To: Ali Bahrami CC: Darren J Moffat , psarc@sac.sfbay.sun.com Subject: Re: PSARC/2007/026 ELF symbol sort sections References: <45A6AE0A.30203@sun.com> <45A76522.9080804@Sun.COM> <45A7C1B1.1090904@sun.com> In-Reply-To: <45A7C1B1.1090904@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 4672 There is some discussion going on right now on security-interest about the various new security features in Vista and how they compare to Solaris. One thing to note that is in Vista is this: - address space layout randomization (so that fixed addresses could not be used in exploits to jump into arbitrary locations, this should be useful along with non-exec stack to make return-into-libc harder), This seems in direct conflict with the statement just made about: 6502792 Same dynamic libraries should be mapped at the same virtual addresses in different processes Ali Bahrami wrote: > Darren J Moffat wrote: >> This looks great, and the scary thing is I think I understood almost >> all of it! >> >> Does this case include changing DTrace to use this or does that not >> happen until later ? >> >> I might have missed it in the text but what is the taxonomy of the new >> sections - I assume they would be Consolidation Private or Project >> Private with a contract to DTrace. Also the release binding - here I >> assume you wanted patch. >> >> -- >> Darren J Moffat > > I put the taxonomy and binding at the end of the initial message. We > (linkers group) see no need to restrict it --- it's all public. > > >Release Binding: Patch/Micro > > > > SHT_SUNW_SYMSORT (.SUNW_dynsymsort): Committed > > SHT_SUNW_TLSSORT (.SUNW_dyntlssort): Committed > > Mapfile DYNSORT and NODYNSORT: Committed > > DT_SUNW_SORTENT: Committed > > DT_SUNW_SYMSORT: Committed > > DT_SUNW_SYMSORTSZ: Committed > > DT_SUNW_TLSSORT: Committed > > DT_SUNW_TLSSORTSZ: Committed > > elfdump -S Committed > > This case does not include changing DTrace. It is a necessary > precondition to doing > so, but the DTrace work will be done in a separate project. > > Although it is not part of this ARC, let me quickly sketch out where I > believe we are heading. The remaining missing piece in solving the > DTrace problem > is how to communicate all of this information about symbol tables, > string tables, > and sort sections, to the DTrace probe context code that needs it. > Currently, > that information resides in userland, in the runtime linker. > > I believe that the right place to solve this will be as part of: > > 6502792 Same dynamic libraries should be mapped at the same > virtual addresses in different processes > > That CR contains a proposal for a new ELF-aware system call for mapping > ELF files. > The runtime linker will use this new mmapfd() system call instead of > mmap() to > map ELF objects. There are many reasons why this would be a big win, > both for some of our high end systems, and for the linker: > > - It lets new hardware take advantage of unique abilities in a timely > fashion, and under the control of the people who actually know what > is needed. > > - Those special hacks disappear, along with any other special kernel > support, when that hardware is no longer supported, so we don't end > up carrying no longer used cruft around in our code. > > mmapfd() would be used for all ELF section mapping, with the exception > of the > mappings done by exec(). One side effect of this approach is that the > kernel will > have explicit knowledge of all ELF mappings in a given process, > something that isn't > true today (we use mmap() --- the kernel doesn't know what the data it > is mmapping > means). This explicit knowledge makes mmapfd() the ideal place for the > kernel, > while it is mapping the file, to harvest and retain the necessary > information > on where the ELF symbol, string table, and sort sections are. Given a > data structure > (AVL tree?) that lets DTrace quickly get to this information, the rest > of the > implementation (a binary search function) will be easy. > > The other way to do this is for the runtime linker to build that data > structure and > somehow communicate it to the kernel. I prefer the mmapfd() idea because > it eliminates > the need for awkward coordination between the kernel and userland. > > - Ali -- blu "The genius of you Americans is that you never make clear-cut stupid moves, only complicated stupid moves which make us wonder at the possibility that there may be something to them which we are missing." - Gamal Abdel Nasser ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From sacadmin Fri Jan 12 12:56:09 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0CKu9Xt019995 for ; Fri, 12 Jan 2007 12:56:09 -0800 (PST) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0CKu6jq013037; Fri, 12 Jan 2007 12:56:07 -0800 (PST) Message-ID: <45A7F5E6.6040203@sun.com> Date: Fri, 12 Jan 2007 12:56:06 -0800 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Brian Utterback CC: Ali Bahrami , Darren J Moffat , psarc@sac.sfbay.sun.com Subject: Re: PSARC/2007/026 ELF symbol sort sections References: <45A6AE0A.30203@sun.com> <45A76522.9080804@Sun.COM> <45A7C1B1.1090904@sun.com> <45A7EF9A.4090900@sun.com> In-Reply-To: <45A7EF9A.4090900@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 4631 RedHat/Fedora Linux does this as well - see the Position Independent Executable section of: http://people.redhat.com/drepper/nonselsec.pdf -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering Brian Utterback wrote: > There is some discussion going on right now on security-interest about > the various new security features in Vista and how they compare to > Solaris. One thing to note that is in Vista is this: > > - address space layout randomization (so that fixed addresses could not > be used in exploits to jump into arbitrary locations, this should be > useful along with non-exec stack to make return-into-libc harder), > > This seems in direct conflict with the statement just made about: > > 6502792 Same dynamic libraries should be mapped at the > same virtual addresses in different processes > > Ali Bahrami wrote: >> Darren J Moffat wrote: >>> This looks great, and the scary thing is I think I understood almost >>> all of it! >>> >>> Does this case include changing DTrace to use this or does that not >>> happen until later ? >>> >>> I might have missed it in the text but what is the taxonomy of the >>> new sections - I assume they would be Consolidation Private or >>> Project Private with a contract to DTrace. Also the release binding - >>> here I assume you wanted patch. >>> >>> -- >>> Darren J Moffat >> >> I put the taxonomy and binding at the end of the initial message. We >> (linkers group) see no need to restrict it --- it's all public. >> >> >Release Binding: Patch/Micro >> > >> > SHT_SUNW_SYMSORT (.SUNW_dynsymsort): Committed >> > SHT_SUNW_TLSSORT (.SUNW_dyntlssort): Committed >> > Mapfile DYNSORT and NODYNSORT: Committed >> > DT_SUNW_SORTENT: Committed >> > DT_SUNW_SYMSORT: Committed >> > DT_SUNW_SYMSORTSZ: Committed >> > DT_SUNW_TLSSORT: Committed >> > DT_SUNW_TLSSORTSZ: Committed >> > elfdump -S Committed >> >> This case does not include changing DTrace. It is a necessary >> precondition to doing >> so, but the DTrace work will be done in a separate project. >> >> Although it is not part of this ARC, let me quickly sketch out where I >> believe we are heading. The remaining missing piece in solving the >> DTrace problem >> is how to communicate all of this information about symbol tables, >> string tables, >> and sort sections, to the DTrace probe context code that needs it. >> Currently, >> that information resides in userland, in the runtime linker. >> >> I believe that the right place to solve this will be as part of: >> >> 6502792 Same dynamic libraries should be mapped at the same >> virtual addresses in different processes >> >> That CR contains a proposal for a new ELF-aware system call for >> mapping ELF files. >> The runtime linker will use this new mmapfd() system call instead of >> mmap() to >> map ELF objects. There are many reasons why this would be a big win, >> both for some of our high end systems, and for the linker: >> >> - It lets new hardware take advantage of unique abilities in a timely >> fashion, and under the control of the people who actually know what >> is needed. >> >> - Those special hacks disappear, along with any other special kernel >> support, when that hardware is no longer supported, so we don't end >> up carrying no longer used cruft around in our code. >> >> mmapfd() would be used for all ELF section mapping, with the exception >> of the >> mappings done by exec(). One side effect of this approach is that the >> kernel will >> have explicit knowledge of all ELF mappings in a given process, >> something that isn't >> true today (we use mmap() --- the kernel doesn't know what the data it >> is mmapping >> means). This explicit knowledge makes mmapfd() the ideal place for the >> kernel, >> while it is mapping the file, to harvest and retain the necessary >> information >> on where the ELF symbol, string table, and sort sections are. Given a >> data structure >> (AVL tree?) that lets DTrace quickly get to this information, the rest >> of the >> implementation (a binary search function) will be easy. >> >> The other way to do this is for the runtime linker to build that data >> structure and >> somehow communicate it to the kernel. I prefer the mmapfd() idea >> because it eliminates >> the need for awkward coordination between the kernel and userland. >> >> - Ali > From sacadmin Fri Jan 12 13:07:51 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0CL7pjJ020421 for ; Fri, 12 Jan 2007 13:07:51 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0CL7oqR008755 for ; Fri, 12 Jan 2007 13:07:50 -0800 (PST) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0CL7oxg010191 for ; Fri, 12 Jan 2007 14:07:50 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBR00C01WU28P00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 12 Jan 2007 14:07:50 -0700 (MST) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBR00DLXXD2HFS5@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Fri, 12 Jan 2007 14:07:50 -0700 (MST) Date: Fri, 12 Jan 2007 14:09:52 -0700 From: Ali Bahrami Subject: Re: PSARC/2007/026 ELF symbol sort sections In-reply-to: <45A7EF9A.4090900@sun.com> Sender: Ali.Bahrami@Sun.COM To: Brian Utterback Cc: Darren J Moffat , psarc@sac.sfbay.sun.com Message-id: <45A7F920.5020908@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <45A6AE0A.30203@sun.com> <45A76522.9080804@Sun.COM> <45A7C1B1.1090904@sun.com> <45A7EF9A.4090900@sun.com> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) Status: RO Content-Length: 1347 Brian Utterback wrote: > There is some discussion going on right now on security-interest about > the various new security features in Vista and how they compare to > Solaris. One thing to note that is in Vista is this: > > - address space layout randomization (so that fixed addresses could not > be used in exploits to jump into arbitrary locations, this should be > useful along with non-exec stack to make return-into-libc harder), > > This seems in direct conflict with the statement just made about: > > 6502792 Same dynamic libraries should be mapped at the > same virtual addresses in different processes No, I don't think there's a conflict here. I am not advocating that dynamic libraries should be mapped at the same virtual addresses in different processes. What I *am* advocating is the mmapfd() system call, which is described in a comment in that CR. In fact, mmapfd() would allow the kernel to do anything it wants. One option would be to put it in the same place in every process, but another equally possible one would be do move it around in every process. 6502792 just happens to be the place where the mmapfd() system call idea is available to everyone to look at. I would have said so when I was responding to Darren's question, but I hadn't seen the discussion in security-interest yet. - Ali From sacadmin Fri Jan 19 09:49:21 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0JHnLFG017937 for ; Fri, 19 Jan 2007 09:49:21 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0JHnKre023011 for ; Fri, 19 Jan 2007 09:49:21 -0800 (PST) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0JHnKuV020604 for ; Fri, 19 Jan 2007 10:49:20 -0700 (MST) Received: from mms27es.sun.com ([150.143.232.134] [150.143.232.134]) by relay22.sun.com with ESMTP for psarc@sac.sfbay.sun.com; Fri, 19 Jan 2007 17:49:20 Z Received: from mms23bas.mms.us.syntegra.com (mms23bas.mms.us.syntegra.com [192.12.251.50]) by mms27es.sun.com with ESMTP for psarc@sac.sfbay.sun.com; Fri, 19 Jan 2007 17:49:18 Z Received: from emvision.com ([199.45.162.234] [199.45.162.234]) by relay23.sun.com with ESMTP for psarc@sac.sfbay.sun.com; Fri, 19 Jan 2007 17:49:10 Z Received: from [198.182.198.2] (pod.emvision.com [198.182.198.2]) by emvision.com (8.13.6/8.13.6) with ESMTP id l0JHn907017327 for ; Fri, 19 Jan 2007 10:49:09 -0700 (MST) Message-Id: <45B10494.9060401@Sun.COM> Date: Fri, 19 Jan 2007 10:49:08 -0700 From: Ali Bahrami User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: 2007/026 ELF symbol sort sections Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (emvision.com [198.182.198.5]); Fri, 19 Jan 2007 10:49:09 -0700 (MST) Status: RO Content-Length: 52 Case has been marked as closed and approved. - Ali