[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