[PATCH] D85024: [llvm-objdump] Implement --prefix option

Vinicius Tinti via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 25 09:13:17 PDT 2020


tinti marked 4 inline comments as done.
tinti added inline comments.


================
Comment at: llvm/test/tools/llvm-objdump/X86/source-interleave-absolute-paths.test:29
+; RUN: llvm-objdump --prefix myprefix/// --source %t.o 2>&1 | FileCheck %s --check-prefix CHECK-TRAILING -DFILE=%t.o
+; CHECK-TRAILING: warning: '[[FILE]]': failed to find source myprefix/Inputs/source-interleave-x86_64.c
----------------
jhenderson wrote:
> You don't need `CHECK-TRAILING`. You can use `CHECK-BROKEN-PREFIX` with `-D ROOT=''`.
In this case I believe I need.

`CHECK-BROKEN-PREFIX` uses `%t2`.
`CHECK-TRAILING` uses `%t`.


================
Comment at: llvm/tools/llvm-objdump/llvm-objdump.cpp:433
+objdumpIsAbsolute(const Twine &path,
+                  sys::path::Style style = sys::path::Style::native) {
+  if (style == sys::path::Style::windows) {
----------------
jhenderson wrote:
> You never specify the `style` parameter so unsurprisingly, the check for `style == sys::path::Style::windows` doesn't work, and the test still fails on Windows. You can see this by looking at the test failures listed by the pre-merge checks near the top of this page. You might want a call to `real_style`.
You are correct. I miss understood the meaning of `Style::native`. I thought it would be set to either `Style::posix` or `Style::native`.

Unfortunately `real_style` is restricted to https://github.com/llvm-mirror/llvm/blob/master/lib/Support/Path.cpp#L39.

Thinking about it I can:
- Add a `#ifdef _WIN32` in `llvm-objdump`. I am really not willing to go with this one but I have seen in other tools such as `llvm-objcopy` [1].
- Make `real_style` public or be able to query the style outside `llvm::sys::path::*` with a helper function. Doesn't look great also. It seems to be designed this way to avoid such queries.
- Try another way to answer "was I built on Windows?"

LLDB has this issue too since GDB does use IS_DIR_ABSOLUTE [3]. It solves it in several ways (usage [4] and [5]):

- `#ifdef` https://github.com/llvm/llvm-project/blob/master/lldb/source/Utility/FileSpec.cpp#L37
- `Triple` https://github.com/llvm/llvm-project/blob/master/lldb/source/Utility/FileSpec.cpp#L76
- indirectly using path https://github.com/llvm/llvm-project/blob/master/lldb/source/Utility/FileSpec.cpp#L310

With all this in mind I think I would go with `Triple(sys::getProcessTriple()).isOSWindows()` implementation. Correct me if I am wrong but on GNU you can only have one binary for one target whereas LLVM one may have one binary to many targets (I don't know if this applies here).

Taking into account CROSS-COMPILING between Linux and Windows: My guess would be to behave based on the **running target** rather than the **compile target**.

Out of ideas. It is becoming a bit complex.

Two more things. Should I care about `__CYGWIN__`, `__MSDOS__`, `__OS2__`? GNU tools care [2].

I would answer no. Maybe only care for `__CYGWIN__`.

```
git grep __CYGWIN__ | wc -l
43
git grep __MSDOS__ | wc -l
3
git grep __OS2__ | wc -l
3
```

Should I use `isAlpha()` like LLDB? There are some restriction about `<drive letter>:` format [6].

[1] See https://github.com/llvm/llvm-project/commit/6dc59629570ae6fe1836cff3ff53912917d17af7#diff-a074a8872d4fe193550d7a651ea18cabR229.
[2] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=include/filenames.h;hb=1ab8d928977f4d9f137f972d03e079555d0f29fa#l35
[3] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/buildsym.c;hb=1ab8d928977f4d9f137f972d03e079555d0f29fa#l519
[4] https://github.com/llvm/llvm-project/blob/e22f0dabcf976668d35595e17645095e97a8177a/lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp#L653.
[5] https://github.com/llvm/llvm-project/blob/bc9b6b33a0d5760370e72ae06c520c25aa8d61c6/lldb/source/Utility/FileSpec.cpp#L59
[6] https://en.wikipedia.org/wiki/Drive_letter_assignment#Common_assignments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85024/new/

https://reviews.llvm.org/D85024



More information about the llvm-commits mailing list