thr3ads.net - llvm dev - [llvm-dev] LLD COFF not closing mmaps to input files? [Oct 2017]

If this information is useful, please help other people find it:
Share via:

Rui Ueyama via llvm-dev

2017-Oct-16 01:59 UTC

[llvm-dev] LLD COFF not closing mmaps to input files?

I think you want to call freeArena() before returning from lld::coff::link.

On Sun, Oct 15, 2017 at 6:57 PM, Andrew Kelley via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I believe this line is the culprit:
>
> COFF/Driver.cpp:102:
>   make<std::unique_ptr<MemoryBuffer>>(std::move(MB)); // take
ownership
>
> Patch forthcoming.
>
>
> On Sun, Oct 15, 2017 at 9:45 PM, Andrew Kelley <superjoe30 at
gmail.com>
> wrote:
>
>> I've got a patched LLD 5.0.0 like this:
>>
>> diff --git a/deps/lld/COFF/Driver.cpp b/deps/lld/COFF/Driver.cpp
>> index 854c3e69..8bab1c11 100644
>> --- a/deps/lld/COFF/Driver.cpp
>> +++ b/deps/lld/COFF/Driver.cpp
>> @@ -1030,7 +1030,7 @@ void LinkerDriver::link(ArrayRef<const char
*>
>> ArgsArr) {
>>    if (!Args.hasArgNoClaim(OPT_INPUT)) {
>>      fixupExports();
>>      createImportLibrary(/*AsLib=*/true);
>> -    exit(0);
>> +    return;
>>    }
>>
>>    // Handle /delayload
>> @@ -1172,9 +1172,6 @@ void LinkerDriver::link(ArrayRef<const char
*>
>> ArgsArr) {
>>
>>    // Write the result.
>>    writeResult(&Symtab);
>> -
>> -  // Call exit to avoid calling destructors.
>> -  exit(0);
>>  }
>>
>>  } // namespace coff
>>
>>
>> I'm getting this error from LLVM:
>> unable to write object file
c:\msys64\home\andy\zig\zig-cache\compiler_rt.obj:
>> The requested operation cannot be performed on a file with a
user-mapped
>> section open.
>>
>> The same process calls LLD with this .obj as  a linker input file, then
>> tries to write to the same .obj file later.
>>
>> I believe LLD is mmapping the .obj file and then not cleaning it up.
>>
>> Can I have some guidance as to where in the code I could discover this
>> and clean it up?
>>
>> Regards,
>> Andrew
>> http://ziglang.org/
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171015/a3995687/attachment.html>

Andrew Kelley via llvm-dev

2017-Oct-16 02:07 UTC

head link

[llvm-dev] LLD COFF not closing mmaps to input files?

Thanks Rui, your suggestion solved the problem perfectly.

diff --git a/lld/COFF/Driver.cpp b/lld/COFF/Driver.cpp
index 8bab1c11..0dabca6e 100644
--- a/lld/COFF/Driver.cpp
+++ b/lld/COFF/Driver.cpp
@@ -61,6 +61,7 @@ bool link(ArrayRef<const char *> Args, raw_ostream
&Diag)
{
       (ErrorOS == &llvm::errs() &&
Process::StandardErrHasColors());
   Driver = make<LinkerDriver>();
   Driver->link(Args);
+  freeArena();
   return !ErrorCount;
 }

Could we get this patch upstream?

On Sun, Oct 15, 2017 at 9:59 PM, Rui Ueyama <ruiu at google.com> wrote:
> I think you want to call freeArena() before returning from lld::coff::link.
>
> On Sun, Oct 15, 2017 at 6:57 PM, Andrew Kelley via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I believe this line is the culprit:
>>
>> COFF/Driver.cpp:102:
>>   make<std::unique_ptr<MemoryBuffer>>(std::move(MB)); //
take ownership
>>
>> Patch forthcoming.
>>
>>
>> On Sun, Oct 15, 2017 at 9:45 PM, Andrew Kelley <superjoe30 at
gmail.com>
>> wrote:
>>
>>> I've got a patched LLD 5.0.0 like this:
>>>
>>> diff --git a/deps/lld/COFF/Driver.cpp b/deps/lld/COFF/Driver.cpp
>>> index 854c3e69..8bab1c11 100644
>>> --- a/deps/lld/COFF/Driver.cpp
>>> +++ b/deps/lld/COFF/Driver.cpp
>>> @@ -1030,7 +1030,7 @@ void LinkerDriver::link(ArrayRef<const
char *>
>>> ArgsArr) {
>>>    if (!Args.hasArgNoClaim(OPT_INPUT)) {
>>>      fixupExports();
>>>      createImportLibrary(/*AsLib=*/true);
>>> -    exit(0);
>>> +    return;
>>>    }
>>>
>>>    // Handle /delayload
>>> @@ -1172,9 +1172,6 @@ void LinkerDriver::link(ArrayRef<const
char *>
>>> ArgsArr) {
>>>
>>>    // Write the result.
>>>    writeResult(&Symtab);
>>> -
>>> -  // Call exit to avoid calling destructors.
>>> -  exit(0);
>>>  }
>>>
>>>  } // namespace coff
>>>
>>>
>>> I'm getting this error from LLVM:
>>> unable to write object file
c:\msys64\home\andy\zig\zig-cache\compiler_rt.obj:
>>> The requested operation cannot be performed on a file with a
user-mapped
>>> section open.
>>>
>>> The same process calls LLD with this .obj as  a linker input file,
then
>>> tries to write to the same .obj file later.
>>>
>>> I believe LLD is mmapping the .obj file and then not cleaning it
up.
>>>
>>> Can I have some guidance as to where in the code I could discover
this
>>> and clean it up?
>>>
>>> Regards,
>>> Andrew
>>> http://ziglang.org/
>>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171015/00369815/attachment.html>

Rui Ueyama via llvm-dev

2017-Oct-16 02:22 UTC

head link

[llvm-dev] LLD COFF not closing mmaps to input files?

lld::coff::LinkerDriver::link is not expected to return, so the patch
doesn't make sense unless you have a local patch to make it return, but
I'm
fine with that change because it is harmless. Please go ahead.

On Sun, Oct 15, 2017 at 7:07 PM, Andrew Kelley <superjoe30 at gmail.com>
wrote:
> Thanks Rui, your suggestion solved the problem perfectly.
>
> diff --git a/lld/COFF/Driver.cpp b/lld/COFF/Driver.cpp
> index 8bab1c11..0dabca6e 100644
> --- a/lld/COFF/Driver.cpp
> +++ b/lld/COFF/Driver.cpp
> @@ -61,6 +61,7 @@ bool link(ArrayRef<const char *> Args, raw_ostream
> &Diag) {
>        (ErrorOS == &llvm::errs() &&
Process::StandardErrHasColors());
>    Driver = make<LinkerDriver>();
>    Driver->link(Args);
> +  freeArena();
>    return !ErrorCount;
>  }
>
> Could we get this patch upstream?
>
> On Sun, Oct 15, 2017 at 9:59 PM, Rui Ueyama <ruiu at google.com>
wrote:
>
>> I think you want to call freeArena() before returning from
>> lld::coff::link.
>>
>> On Sun, Oct 15, 2017 at 6:57 PM, Andrew Kelley via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> I believe this line is the culprit:
>>>
>>> COFF/Driver.cpp:102:
>>>   make<std::unique_ptr<MemoryBuffer>>(std::move(MB));
// take ownership
>>>
>>> Patch forthcoming.
>>>
>>>
>>> On Sun, Oct 15, 2017 at 9:45 PM, Andrew Kelley <superjoe30 at
gmail.com>
>>> wrote:
>>>
>>>> I've got a patched LLD 5.0.0 like this:
>>>>
>>>> diff --git a/deps/lld/COFF/Driver.cpp
b/deps/lld/COFF/Driver.cpp
>>>> index 854c3e69..8bab1c11 100644
>>>> --- a/deps/lld/COFF/Driver.cpp
>>>> +++ b/deps/lld/COFF/Driver.cpp
>>>> @@ -1030,7 +1030,7 @@ void LinkerDriver::link(ArrayRef<const
char *>
>>>> ArgsArr) {
>>>>    if (!Args.hasArgNoClaim(OPT_INPUT)) {
>>>>      fixupExports();
>>>>      createImportLibrary(/*AsLib=*/true);
>>>> -    exit(0);
>>>> +    return;
>>>>    }
>>>>
>>>>    // Handle /delayload
>>>> @@ -1172,9 +1172,6 @@ void LinkerDriver::link(ArrayRef<const
char *>
>>>> ArgsArr) {
>>>>
>>>>    // Write the result.
>>>>    writeResult(&Symtab);
>>>> -
>>>> -  // Call exit to avoid calling destructors.
>>>> -  exit(0);
>>>>  }
>>>>
>>>>  } // namespace coff
>>>>
>>>>
>>>> I'm getting this error from LLVM:
>>>> unable to write object file
c:\msys64\home\andy\zig\zig-cache\compiler_rt.obj:
>>>> The requested operation cannot be performed on a file with a
user-mapped
>>>> section open.
>>>>
>>>> The same process calls LLD with this .obj as  a linker input
file, then
>>>> tries to write to the same .obj file later.
>>>>
>>>> I believe LLD is mmapping the .obj file and then not cleaning
it up.
>>>>
>>>> Can I have some guidance as to where in the code I could
discover this
>>>> and clean it up?
>>>>
>>>> Regards,
>>>> Andrew
>>>> http://ziglang.org/
>>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171015/d991bc2c/attachment-0001.html>

llvm dev - Oct 2017 - LLD COFF not closing mmaps to input files?

[llvm-dev] LLD COFF not closing mmaps to input files?

[llvm-dev] LLD COFF not closing mmaps to input files?

[llvm-dev] LLD COFF not closing mmaps to input files?