[llvm] r217985 - [llvm-objdump] clean up test cases now that build bots are green

[Jim Grosbach]

> On Sep 19, 2014, at 8:14 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> On 18 September 2014 12:56, Nick Kledzik <kledzik at apple.com> wrote:
>> 
>> On Sep 18, 2014, at 7:40 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>> BTW, any reason for adding this to llvm-objdump instead of llvm-readobj?
>>> 
>>> The rule of the thumb is that llvm-readobj is whatever we want it to
>>> be for testing. llvm-objdump is intended as user tool, a replacement
>>> for the system objdump.
>> Thanks, I did not know of that distinction.  But I’m still not sure where there options should fall.  Xcode ships with command line tools nm, otool, and dyldinfo.  Xcode/Darwin does not have an “objdump” tool.  So where should otool/dyldinfo functionality go?  It is needed by test cases and eventually as a replacement for otool/dyldinfo.
>> 
>> My recent changes were to add dyldinfo functionality to llvm-objdump.
>> 
>> Kevin Enderby already added Xcode’s nm functionality to llvm-nm, and is now adding otool functionality to llvm-objdjump.
> 
> I guess the ideal situation would be to have a llvm-otool and llvm-dyldinfo :-)

I don’t follow why that would be better. Can you elaborate a bit? The current precedent for this sort of thing is things like sniffing argv[0] and using symlinks or something like that if we want different behavior based on how the tool was invoked. For cross-platform testing, a —flavor option will do the trick. This is basically what both the clang driver and LLD do and it seems to work pretty well.

-Jim


> If the features you are adding are suitable for developer use and not
> just testing support, then llvm-objdump might be a reasonable place to
> hold then for now.
> 
> Please just add a fixme along the lines of "objdump is not a native
> MachO tool, move this to llvm-otool/llvm-dyldinfo once we have one”