[PATCH] D61049: Let llvm-cvtres (and lld-link) report duplicate resources
Nico Weber via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sun Apr 28 17:49:55 PDT 2019
thakis added a comment.
In D61049#1479100 <https://reviews.llvm.org/D61049#1479100>, @uweigand wrote:
> It looks like this new test case fails on big-endian systems, like this:
> http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/24725
>
> /home/uweigand/sandbox/buildbot/clang-s390x-linux/llvm/test/tools/llvm-cvtres/duplicate.test:19:7: error: NAME: expected string not found in input
> NAME: duplicate resource: type "TYPEFOO"/name "NAMEBAR"/language 1033, in {{.*}}name1.res and in {{.*}}name2.res
> ^
> <stdin>:1:1: note: scanning from here
> duplicate resource: type "吀夀倀䔀䘀伀伀"/name "一䄀䴀䔀䈀䄀刀"/language 1033, in /home/uweigand/sandbox/buildbot/clang-s390x-linux/stage1/test/tools/llvm-cvtres/Output/duplicate.test.tmp.dir/name1.res and in /home/uweigand/sandbox/buildbot/clang-s390x-linux/stage1/test/tools/llvm-cvtres/Output/duplicate.test.tmp.dir/name2.res
>
>
>
> This seems like an endian issue when converting (Windows) UTF16 strings. I believe those need to be assumed as default little-endian in the absence of a byte-order mark, even on big-endian system.
>
> Code in WindowsResourceParser::TreeNode::addChild seems to handle this explicitly. We may need a similar fix here.
I tried to fix this in r359414. Sorry for the breakage, and sorry for the slow turnaround, I was away on Friday.
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D61049/new/
https://reviews.llvm.org/D61049
More information about the llvm-commits
mailing list