maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Object/nm-darwin-m.test

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

58 lines
3.0 KiB
Plaintext
Raw Normal View History

[llvm-ar][llvm-nm][llvm-size] Change -long-option to --long-option in tests. NFC llvm-svn: 359688
2019-05-01 23:31:15 +08:00
RUN: llvm-nm --format=darwin %p/Inputs/darwin-m-test1.mach0-armv7 \
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-06 05:21:57 +08:00
RUN: | FileCheck %s -check-prefix test1
[llvm-ar][llvm-nm][llvm-size] Change -long-option to --long-option in tests. NFC llvm-svn: 359688
2019-05-01 23:31:15 +08:00
RUN: llvm-nm --format=darwin %p/Inputs/darwin-m-test2.macho-i386 \
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-06 05:21:57 +08:00
RUN: | FileCheck %s -check-prefix test2
Added the -m option as an alias for -format=darwin to llvm-nm and llvm-size which is what the darwin tools use for the Mach-O format output. llvm-svn: 211326
2014-06-20 08:04:16 +08:00
RUN: llvm-nm -m %p/Inputs/darwin-m-test3.macho-x86-64 \
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-06 05:21:57 +08:00
RUN: | FileCheck %s -check-prefix test3
# This is testing that the various bits in the n_desc feild are correct
test1: 00000001 (absolute) non-external _a
test1: 00000008 (common) (alignment 2^2) external _c
test1: 0000000a (__DATA,__data) non-external [no dead strip] _d
test1: 00000004 (__TEXT,__text) non-external [alt entry] _e
test1: 00000000 (__TEXT,__text) non-external [symbol resolver] _r
test1: 00000008 (__TEXT,__text) non-external [Thumb] _t
# This is testing that an N_INDR symbol gets its alias name, the "(for ...)"
test2: (undefined) external __i
test2: (indirect) external _i (for __i)
# This is testing is using darwin-m-test3.macho-x86-64 that is linked with
# dylibs that have the follow set of -install_names:
Limit dyld image suffixes guessed by guessLibraryShortName() Summary: guessLibraryShortName() separates a full Mach-O dylib install name path into a short name and a dyld image suffix. The short name is the name of the dylib without its path or extension. The dyld image suffix is a string used by dyld to load variants of dylibs if available at runtime; for example, "when binding this process, load 'debug' variants of all required dylibs." dyld knows exactly what the image suffix is, but by convention diagnostic tools such as llvm-nm attempt to guess suffix names by looking at the install name path. These dyld image suffixes are separated from the short name by a '_' character. Because the '_' character is commonly used to separate words in filenames guessLibraryShortName() cannot reliably separate a dylib's short name from an arbitrary image suffix; imagine if both the short name and the suffix contains an '_' character! To better deal with this ambiguity, guessLibraryShortName() will recognize only "_debug" and "_profile" as valid Suffix values. Calling code needs to be tolerant of guessLibraryShortName() guessing incorrectly. The previous implementation of guessLibraryShortName() did not allow '_' characters to appear in short names. When present, the short name would be truncated, e.g., "libcompiler_rt" => "libcompiler". This change allows "libcompiler_rt" and "libcompiler_rt_debug" to both be recognized as "libcompiler_rt". rdar://47412244 Reviewers: kledzik, lhames, pete Reviewed By: pete Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56978 llvm-svn: 352104
2019-01-25 04:59:44 +08:00
# Foo.framework/Foo
# /System/Library/Frameworks/FooPath.framework/FooPath
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-06 05:21:57 +08:00
# FooSuffix.framework/FooSuffix_debug
# /System/Library/Frameworks/FooPathSuffix.framework/FooPathSuffix_profile
# FooVers.framework/Versions/A/FooVers
# /System/Library/Frameworks/FooPathVers.framework/Versions/B/FooPathVers
# libx.dylib
# libxSuffix_profile.dylib
# /usr/local/lib/libxPathSuffix_debug.dylib
# libATS.A_profile.dylib
# /usr/lib/libPathATS.A_profile.dylib
# QT.A.qtx
# /lib/QTPath.qtx
Limit dyld image suffixes guessed by guessLibraryShortName() Summary: guessLibraryShortName() separates a full Mach-O dylib install name path into a short name and a dyld image suffix. The short name is the name of the dylib without its path or extension. The dyld image suffix is a string used by dyld to load variants of dylibs if available at runtime; for example, "when binding this process, load 'debug' variants of all required dylibs." dyld knows exactly what the image suffix is, but by convention diagnostic tools such as llvm-nm attempt to guess suffix names by looking at the install name path. These dyld image suffixes are separated from the short name by a '_' character. Because the '_' character is commonly used to separate words in filenames guessLibraryShortName() cannot reliably separate a dylib's short name from an arbitrary image suffix; imagine if both the short name and the suffix contains an '_' character! To better deal with this ambiguity, guessLibraryShortName() will recognize only "_debug" and "_profile" as valid Suffix values. Calling code needs to be tolerant of guessLibraryShortName() guessing incorrectly. The previous implementation of guessLibraryShortName() did not allow '_' characters to appear in short names. When present, the short name would be truncated, e.g., "libcompiler_rt" => "libcompiler". This change allows "libcompiler_rt" and "libcompiler_rt_debug" to both be recognized as "libcompiler_rt". rdar://47412244 Reviewers: kledzik, lhames, pete Reviewed By: pete Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56978 llvm-svn: 352104
2019-01-25 04:59:44 +08:00
# /usr/lib/libfoo_bar.dylib
# /usr/lib/libfoo_bar_profile.dylib
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-06 05:21:57 +08:00
# /usr/lib/libSystem.B.dylib
Limit dyld image suffixes guessed by guessLibraryShortName() Summary: guessLibraryShortName() separates a full Mach-O dylib install name path into a short name and a dyld image suffix. The short name is the name of the dylib without its path or extension. The dyld image suffix is a string used by dyld to load variants of dylibs if available at runtime; for example, "when binding this process, load 'debug' variants of all required dylibs." dyld knows exactly what the image suffix is, but by convention diagnostic tools such as llvm-nm attempt to guess suffix names by looking at the install name path. These dyld image suffixes are separated from the short name by a '_' character. Because the '_' character is commonly used to separate words in filenames guessLibraryShortName() cannot reliably separate a dylib's short name from an arbitrary image suffix; imagine if both the short name and the suffix contains an '_' character! To better deal with this ambiguity, guessLibraryShortName() will recognize only "_debug" and "_profile" as valid Suffix values. Calling code needs to be tolerant of guessLibraryShortName() guessing incorrectly. The previous implementation of guessLibraryShortName() did not allow '_' characters to appear in short names. When present, the short name would be truncated, e.g., "libcompiler_rt" => "libcompiler". This change allows "libcompiler_rt" and "libcompiler_rt_debug" to both be recognized as "libcompiler_rt". rdar://47412244 Reviewers: kledzik, lhames, pete Reviewed By: pete Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56978 llvm-svn: 352104
2019-01-25 04:59:44 +08:00
# to test that MachOObjectFile::guessLibraryShortName() is correctly parsing
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-06 05:21:57 +08:00
# them into their short names.
test3: 0000000100000000 (__TEXT,__text) [referenced dynamically] external __mh_execute_header
test3: (undefined) external _atsPathVersSuffix (from libPathATS)
test3: (undefined) external _atsVersSuffix (from libATS)
test3: (undefined) external _foo (from Foo)
test3: (undefined) external _fooPath (from FooPath)
test3: (undefined) external _fooPathSuffix (from FooPathSuffix)
test3: (undefined) external _fooPathVers (from FooPathVers)
test3: (undefined) external _fooSuffix (from FooSuffix)
test3: (undefined) external _fooVers (from FooVers)
Limit dyld image suffixes guessed by guessLibraryShortName() Summary: guessLibraryShortName() separates a full Mach-O dylib install name path into a short name and a dyld image suffix. The short name is the name of the dylib without its path or extension. The dyld image suffix is a string used by dyld to load variants of dylibs if available at runtime; for example, "when binding this process, load 'debug' variants of all required dylibs." dyld knows exactly what the image suffix is, but by convention diagnostic tools such as llvm-nm attempt to guess suffix names by looking at the install name path. These dyld image suffixes are separated from the short name by a '_' character. Because the '_' character is commonly used to separate words in filenames guessLibraryShortName() cannot reliably separate a dylib's short name from an arbitrary image suffix; imagine if both the short name and the suffix contains an '_' character! To better deal with this ambiguity, guessLibraryShortName() will recognize only "_debug" and "_profile" as valid Suffix values. Calling code needs to be tolerant of guessLibraryShortName() guessing incorrectly. The previous implementation of guessLibraryShortName() did not allow '_' characters to appear in short names. When present, the short name would be truncated, e.g., "libcompiler_rt" => "libcompiler". This change allows "libcompiler_rt" and "libcompiler_rt_debug" to both be recognized as "libcompiler_rt". rdar://47412244 Reviewers: kledzik, lhames, pete Reviewed By: pete Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56978 llvm-svn: 352104
2019-01-25 04:59:44 +08:00
test3: (undefined) external _foo_bar (from libfoo_bar)
test3: (undefined) external _foo_barSuffix (from libfoo_barSuffix)
test3: 0000000100000e50 (__TEXT,__text) external _main
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-06 05:21:57 +08:00
test3: (undefined) external _qt (from QT)
test3: (undefined) external _qtPath (from QTPath)
test3: (undefined) external _x (from libx)
test3: (undefined) external _xPathSuffix (from libxPathSuffix)
test3: (undefined) external _xSuffix (from libxSuffix)
test3: (undefined) external dyld_stub_binder (from libSystem)