This is an archive of the discontinued LLVM Phabricator instance.

Let llvm-cvtres (and lld-link) report duplicate resources
ClosedPublic

Authored by thakis on Apr 23 2019, 6:39 PM.

Details

Summary

If two .res files contain the same resource, cvtres.exe (and hence
link.exe) reject the input with this message:

CVTRES : fatal error CVT1100: duplicate resource.  type:STRING, name:101, language:0x0409
LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

llvm-cvtres (and lld-link) used to silently pick one of the duplicate
resources instead. This patch makes them report an error as well.
We slightly improve on cvtres by printing the name of two .res files
containing duplicate entries as well.

Diff Detail

Repository
rL LLVM

Event Timeline

thakis created this revision.Apr 23 2019, 6:39 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 23 2019, 6:39 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
thakis updated this revision to Diff 196367.Apr 23 2019, 6:52 PM

better name test

mstorsjo accepted this revision.Apr 23 2019, 10:55 PM

LGTM

I guess it's better to keep tests standalone and not use llvm-rc for the input to the test here.

llvm/test/tools/llvm-cvtres/duplicate.test
11 ↗(On Diff #196367)

What output file does this write into? A temporary file that is removed afterwards - in what directory? (Would it be better to pass a named -out:%t.obj to make sure it doesn't do stray writes outside of the designated directory?)

llvm/tools/llvm-cvtres/llvm-cvtres.cpp
105 ↗(On Diff #196367)

What does this particular changed line do, with respect to the rest of the patch?

This revision is now accepted and ready to land.Apr 23 2019, 10:55 PM
thakis marked 2 inline comments as done.Apr 24 2019, 3:16 AM

Thanks! Please let me know what to do about the two comments below :)

llvm/test/tools/llvm-cvtres/duplicate.test
11 ↗(On Diff #196367)

The default output name is the name of the first input file, with .res replaced with .obj, so that's in %t.dir already. Furthermore, the output file is only created once all input files have been parsed successfully, and parsing input files fails here. I can add an explicit out: flag if you think it makes the test easier to read, but it doesn't have an effect.

llvm/tools/llvm-cvtres/llvm-cvtres.cpp
105 ↗(On Diff #196367)

It's unrelated to the patch. I had read this file while working on this patch, wondered what the false meant, opened the .h file that declares this function to add a /*ArgName=*/ comment, and then realized that false is the default argument for this parameter already, so I figured I'd just remove it. I can land this in a separate commit if you want.

I'll land the false removal in a separate commit and keep the test as-is.

mstorsjo added inline comments.Apr 24 2019, 4:32 AM
llvm/test/tools/llvm-cvtres/duplicate.test
11 ↗(On Diff #196367)

Ok, so it's not an issue. Go ahead whichever way you prefer then, it doesn't really hurt this way (and the risk of it becoming an issue later is also minimal), it just came to my mind while reviewing it.

llvm/tools/llvm-cvtres/llvm-cvtres.cpp
105 ↗(On Diff #196367)

Yes, please do so, it's quite distracting/confusing here.

This revision was automatically updated to reflect the committed changes.

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.

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.

I tried to fix this in r359414. Sorry for the breakage, and sorry for the slow turnaround, I was away on Friday.

Yes, it looks like the build bots are green again. Thanks!