On 5/16/22 17:16, Alexander Monakov wrote:
> On Mon, 16 May 2022, Martin Liška wrote:
>
>> I've implemented first version of the patch, please take a look.
>
> I'll comment on the patch, feel free to inform me when I should back off
> with forcing my opinion in this thread :)
I do really
On Mon, May 16, 2022 at 5:16 PM Alexander Monakov wrote:
>
> On Mon, 16 May 2022, Martin Liška wrote:
>
> > I've implemented first version of the patch, please take a look.
>
> I'll comment on the patch, feel free to inform me when I should back off
> with forcing my opinion in this thread :)
I
On Mon, 16 May 2022, Martin Liška wrote:
> I've implemented first version of the patch, please take a look.
I'll comment on the patch, feel free to inform me when I should back off
with forcing my opinion in this thread :)
> --- a/include/plugin-api.h
> +++ b/include/plugin-api.h
> @@ -483,6
On Mon, 16 May 2022, Rui Ueyama wrote:
> > @Rui: Am I correct that you're interested in thread-safe claim_file? Is
> > there any
> > other function being called paralely?
>
> Yes, I want a thread-safe claim_file. And that function seems to be
> the only function in mold that is called in
On Mon, May 16, 2022 at 8:04 PM Martin Liška wrote:
>
> On 5/16/22 12:28, Richard Biener wrote:
> > On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote:
> >>
> >> Version handshaking is doable, but it feels like we are over-designing
> >> an API, given that the real providers of this plugin API
On 5/16/22 12:28, Richard Biener wrote:
> On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote:
>>
>> Version handshaking is doable, but it feels like we are over-designing
>> an API, given that the real providers of this plugin API are only GCC
>> and LLVM and the users of the API are BFD ld, gold
On Mon, May 16, 2022 at 6:28 PM Richard Biener
wrote:
>
> On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote:
> >
> > Version handshaking is doable, but it feels like we are over-designing
> > an API, given that the real providers of this plugin API are only GCC
> > and LLVM and the users of the
On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote:
>
> Version handshaking is doable, but it feels like we are over-designing
> an API, given that the real providers of this plugin API are only GCC
> and LLVM and the users of the API are BFD ld, gold and mold. It is
> unlikely that we'll have
On Mon, May 16, 2022 at 11:50 AM Jan Hubicka wrote:
>
> > On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote:
> > >>
> > >> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
> > >> is useful if bugs are discovered in old versions that you by definition
> > >> cannot
> >
Version handshaking is doable, but it feels like we are over-designing
an API, given that the real providers of this plugin API are only GCC
and LLVM and the users of the API are BFD ld, gold and mold. It is
unlikely that we'll have dozens of more compilers or linkers in the
near future. So, I
> On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote:
> >>
> >> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
> >> is useful if bugs are discovered in old versions that you by definition
> >> cannot
> >> fix but can apply workarounds to. Note the actual compiler used
On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote:
>>
>> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
>> is useful if bugs are discovered in old versions that you by definition
>> cannot
>> fix but can apply workarounds to. Note the actual compiler used might still
>
> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
> is useful if bugs are discovered in old versions that you by definition cannot
> fix but can apply workarounds to. Note the actual compiler used might still
> differ. Note that still isn't clean API documentation /
On Mon, 16 May 2022, Richard Biener wrote:
> Is there an API document besides the header itself somewhere?
It's on the wiki: https://gcc.gnu.org/wiki/whopr/driver
(sadly the v3 entrypoint was added there without documentation)
Alexander
On Mon, May 16, 2022 at 10:37 AM Rui Ueyama via Gcc-patches
wrote:
>
> On Mon, May 16, 2022 at 2:38 PM Alexander Monakov wrote:
> >
> > On Mon, 16 May 2022, Rui Ueyama wrote:
> >
> > > If it is a guaranteed behavior that GCC of all versions that support
> > > only get_symbols_v2 don't leave a
On Mon, May 16, 2022 at 2:38 PM Alexander Monakov wrote:
>
> On Mon, 16 May 2022, Rui Ueyama wrote:
>
> > If it is a guaranteed behavior that GCC of all versions that support
> > only get_symbols_v2 don't leave a temporary file behind if it is
> > suddenly disrupted during get_symbols_v2
On Mon, 16 May 2022, Rui Ueyama wrote:
> If it is a guaranteed behavior that GCC of all versions that support
> only get_symbols_v2 don't leave a temporary file behind if it is
> suddenly disrupted during get_symbols_v2 execution, then yes, mold can
> restart itself when get_symbols_v2 is called
On Sun, May 15, 2022 at 8:07 PM Alexander Monakov wrote:
>
> On Sun, 15 May 2022, Rui Ueyama wrote:
>
> > > Regarding files, as far as I can tell, GCC plugin will leave a
> > > 'resolution file'
> > > on disk, but after re-exec it would recreate it anyway.
> >
> > Does it recreate a temporary
On Sun, 15 May 2022, Rui Ueyama wrote:
> > Regarding files, as far as I can tell, GCC plugin will leave a 'resolution
> > file'
> > on disk, but after re-exec it would recreate it anyway.
>
> Does it recreate a temporary file with the same file name so that
> there's no temporary file left on
On Sun, May 15, 2022 at 7:37 PM Alexander Monakov wrote:
>
> On Sun, 15 May 2022, Rui Ueyama wrote:
>
> > > Can you simply restart the linker on first call to get_symbols_v2 instead?
> >
> > I could, but it may not be a safe timing to call exec(2). I believe we
> > are expected to call
On Sun, 15 May 2022, Rui Ueyama wrote:
> > Can you simply restart the linker on first call to get_symbols_v2 instead?
>
> I could, but it may not be a safe timing to call exec(2). I believe we
> are expected to call cleanup_hook after calling all_symbols_read_hook,
> and it is not clear what
On Sun, May 15, 2022 at 6:09 PM Alexander Monakov wrote:
>
> On Sun, 15 May 2022, Rui Ueyama wrote:
>
> > > Makes sense, but I still don't understand why mold wants to discover in
> > > advance whether the plugin is going to use get_symbols_v3. How would it
> > > help with what mold does today to
On Sun, 15 May 2022, Rui Ueyama wrote:
> > Makes sense, but I still don't understand why mold wants to discover in
> > advance whether the plugin is going to use get_symbols_v3. How would it
> > help with what mold does today to handle the _v2 case?
>
> Currently, mold restarts itself to reset
On Sun, May 15, 2022 at 4:51 PM Alexander Monakov wrote:
>
> On Sun, 15 May 2022, Rui Ueyama wrote:
>
> > > Is that a good tradeoff in the LTO case though? I believe you cannot
> > > assume
> > > the plugin to be thread-safe, so you're serializing its API calls, right?
> > > But the plugin is
On Sun, 15 May 2022, Rui Ueyama wrote:
> > Is that a good tradeoff in the LTO case though? I believe you cannot assume
> > the plugin to be thread-safe, so you're serializing its API calls, right?
> > But the plugin is doing a lot of work, so using the index to feed it with as
> > few LTO objects
On Sun, May 15, 2022 at 3:53 PM Alexander Monakov wrote:
>
> On Sun, 15 May 2022, Rui Ueyama wrote:
>
> [snip]
> > > So get_symbols_v3 allows the linker to discard an LTO .o file to solve
> > > this.
> > >
> > > In absence of get_symbols_v3 mold tries to ensure correctness by
> > > restarting
>
On Sun, 15 May 2022, Rui Ueyama wrote:
[snip]
> > So get_symbols_v3 allows the linker to discard an LTO .o file to solve this.
> >
> > In absence of get_symbols_v3 mold tries to ensure correctness by restarting
> > itself while appending a list of .o files to be discarded to its command
> >
On Fri, May 6, 2022 at 10:47 PM Alexander Monakov wrote:
>
>
>
> On Thu, 5 May 2022, Martin Liška wrote:
>
> > On 5/5/22 12:52, Alexander Monakov wrote:
> > > Feels a bit weird to ask, but before entertaining such an API extension,
> > > can we step back and understand the v3 variant of
CCing mold's author.
On 5/6/22 16:46, Alexander Monakov wrote:
>
>
> On Thu, 5 May 2022, Martin Liška wrote:
>
>> On 5/5/22 12:52, Alexander Monakov wrote:
>>> Feels a bit weird to ask, but before entertaining such an API extension,
>>> can we step back and understand the v3 variant of
On Thu, 5 May 2022, Martin Liška wrote:
> On 5/5/22 12:52, Alexander Monakov wrote:
> > Feels a bit weird to ask, but before entertaining such an API extension,
> > can we step back and understand the v3 variant of get_symbols? It is not
> > documented, and from what little I saw I did not get
On 5/5/22 12:52, Alexander Monakov wrote:
> Feels a bit weird to ask, but before entertaining such an API extension,
> can we step back and understand the v3 variant of get_symbols? It is not
> documented, and from what little I saw I did not get the "motivation" for
> its existence (what it is
On Thu, 5 May 2022, Richard Biener via Gcc-patches wrote:
> > I think they should simply try to not register LDPT_GET_SYMBOLS or
> > LDPT_GET_SYMBOLS_V2 with the plugin in the onload hook and if
> > that fails they will know the plugin doesn't support V3 only. I suppose
> > it should work to
On Thu, May 5, 2022 at 8:15 AM Richard Biener
wrote:
>
> On Wed, May 4, 2022 at 3:31 PM Martin Liška wrote:
> >
> > On 5/4/22 15:10, Alexander Monakov wrote:
> > > On Wed, 4 May 2022, Martin Liška wrote:
> > >
> > >> On 5/4/22 14:32, Alexander Monakov wrote:
> > >>> On Wed, 4 May 2022, Martin
On Wed, May 4, 2022 at 3:31 PM Martin Liška wrote:
>
> On 5/4/22 15:10, Alexander Monakov wrote:
> > On Wed, 4 May 2022, Martin Liška wrote:
> >
> >> On 5/4/22 14:32, Alexander Monakov wrote:
> >>> On Wed, 4 May 2022, Martin Liška wrote:
> >>>
> The patch is a follow-up of the discussion
On Wed, 4 May 2022 15:31:32 +0200
Martin Liška wrote:
> On 5/4/22 15:10, Alexander Monakov wrote:
> > On Wed, 4 May 2022, Martin Liška wrote:
> >
> >> On 5/4/22 14:32, Alexander Monakov wrote:
> >>> On Wed, 4 May 2022, Martin Liška wrote:
> >>>
> The patch is a follow-up of the
On 5/4/22 15:10, Alexander Monakov wrote:
> On Wed, 4 May 2022, Martin Liška wrote:
>
>> On 5/4/22 14:32, Alexander Monakov wrote:
>>> On Wed, 4 May 2022, Martin Liška wrote:
>>>
The patch is a follow-up of the discussion we've got in:
On Wed, 4 May 2022, Martin Liška wrote:
> On 5/4/22 14:32, Alexander Monakov wrote:
> > On Wed, 4 May 2022, Martin Liška wrote:
> >
> >> The patch is a follow-up of the discussion we've got in:
> >> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593901.html
> >>
> >> Mold linker would
4,3 +1554,8 @@ onload (struct ld_plugin_tv *tv)
>>
>>return LDPS_OK;
>> }
>> +
>> +/* The following symbols are used for dynamic detection of plug-in features
>> + from linker side. */
>> +
>> +bool supports_get_symbols_v3;
From
On Wed, 4 May 2022, Martin Liška wrote:
> The patch is a follow-up of the discussion we've got in:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593901.html
>
> Mold linker would appreciate knowing in advance if get_symbols_v3 is supported
> by a GCC plug-in or not.
>
> Ready to be
The patch is a follow-up of the discussion we've got in:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593901.html
Mold linker would appreciate knowing in advance if get_symbols_v3 is supported
by a GCC plug-in or not.
Ready to be installed?
Thanks,
Martin
lto-plugin/ChangeLog:
*
40 matches
Mail list logo
