summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python/interface
diff options
context:
space:
mode:
authorChandler Carruth <chandlerc@gmail.com>2011-10-01 00:37:35 +0000
committerChandler Carruth <chandlerc@gmail.com>2011-10-01 00:37:35 +0000
commit6d913a188459320d819012d59b64abe02efa8e89 (patch)
tree24c47006bfa3db63ab7cf45896da4339535932e1 /lldb/scripts/Python/interface
parent2c0a65ee78bccf11b4c7c08730da2636fb79b45a (diff)
downloadbcm5719-llvm-6d913a188459320d819012d59b64abe02efa8e89.tar.gz
bcm5719-llvm-6d913a188459320d819012d59b64abe02efa8e89.zip
Revert r140604: "Let -B work for ld paths on Linux."
This patch may do what it describes, it may not. It's hard to tell as its completely unclear what this is supposed to do. There are also no test cases. More importantly, this seems to have broken lots of linker invocations on multilib Linux systems. The manual pages for 'ld' on Linux mention translating a '=' at the beginning of the path into a *configure time* sysroot prefix (this is, I believe, distinct from the --sysroot flag which 'ld' also can support). I tested this with a normal binutils 'ld', a binutils 'ld' with the sysroot flag enabled, and gold with the sysroot flag enabled, and all of them try to open the path '=/lib/../lib32', No translation occurs. I think at the very least inserting an '=' needs to be conditioned on some indication that it is supported and desired. I'm also curious to see what toolchain and whan environment cause it to actually make a difference. I'm going to add a test case for basic sanity of Linux 'ld' invocations from Clang in a follow-up commit that would have caught this. llvm-svn: 140908
Diffstat (limited to 'lldb/scripts/Python/interface')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud