[llvm] [test] Remove non-portable EISDIR test from macho-disassemble-g-dsym.test

[mgorny]

Summary

Remove the test checking error message for 'is a directory'. It does
not seem to serve any real purpose, and it relies on matching platform
error strings which are unpredictable and makes the test fragile.
Furthermore, it fails on NetBSD where read() works on directories,
and therefore does not return EISDIR at all.

Fixes rL362141.

[mtrent]

"It does not seem to serve any real purpose..."

In the past, reviewers in the LLVM community required those of us working in llvm-objdump to supply test cases that exercise every error condition we may encounter when parsing Mach-O binaries, even in cases when the logic is simple and verifiable via code inspection. To be honest with you, this has been a bit of a burden for us, as sometimes constructing a binary that triggers a very specific error condition can be difficult.

In this case, I do have people filing bug reports against this behavior (printing the wrong error message when passing bad input) so I added the test to satisfy the LLVM community's previous requirement that all error states be tested in llvm-objdump, and as justification to close the bug reports.

But that said, I am 100% OK with relaxing the requirement that we need to test every error case in llvm-objdump going forward.

[krytarowski]

whereas others emit "is a directory

I don't know who is 'others' but NetBSD allows opening and reading directories as they would be files.

If there is requirement to reject reading of directories in llvm-objdump or underlying API, let us know and we will add extra check in the LLVM code using fstat(2) & S_ISDIR().

As @mgorny stated, this check might have no real purpose as reading directories will fail in one or another way virtually always and the tests check obvious behavior.

[mgorny]

The more general question is: should we really reject directories here? I mean, sure, it probably makes no sense to process them but is there a technical reason to prevent user from doing it here? And if yes, then what about all the other contexts where read() will succeed on a directory?

[mgorny]

@pete, do you have any opinion on this?

[mtrent]

Given the problems we've seen with windows and netbsd, I think it makes sense for llvm-obdump to have a better, more bespoke error case, one that is stable on all platforms. so let's pull this test.

Should llvm-objdump allow arbitrary directories to be passed into the -dsym flag? No. And I have no idea what error netbsd actually fails with here. Arguably it should allow .dSYM bundle directories; and that would also obviate a need for this exact test (to be replaced with other error tests for malformed .dSYM bundles, unreadable plist files, etc.)

[mgorny]

NetBSD fails with unrecognized file format because the data read() from a directory (i.e. the directory entries) doesn't look like any valid object type.

[krytarowski]

If we want to reject opening directories we shall do it during open(2)/fopen(3).

llvm/trunk/test/tools/llvm-objdump/X86/macho-disassemble-g-dsym.test

 // RUN: llvm-objdump -m -d -g -dsym %p/Inputs/hello-macho-fat.dwarf %p/Inputs/hello-macho-thin | FileCheck -check-prefix MACHO_DSYM %s
 // RUN: llvm-objdump -m -d -g -dsym %p/Inputs/hello-macho-thin.dwarf %p/Inputs/hello-macho-thin | FileCheck -check-prefix MACHO_DSYM %s
 
 MACHO_DSYM: (__TEXT,__text) section
 
 // RUN: llvm-objdump -m -d -g -dsym %p/../Inputs/libbogus11.a %p/../../dsymutil/Inputs/basic.macho.x86_64 2>&1 | FileCheck -check-prefix BAD_INPUT %s
 
 BAD_INPUT: is not a Mach-O or Universal file type.
-
-// RUN: not llvm-objdump -m -d -g -dsym %p/Inputs %p/Inputs/hello-macho-thin 2>&1 | FileCheck -check-prefix DIRECTORY %s
-
-// Windows will emit "Is a directory", whereas others emit "is a directory"
-DIRECTORY: {{[i|I]}}s a directory