On Tue, Jul 12, 2022 at 9:31 PM Martin Liška wrote:
>
> On 7/12/22 13:50, Rui Ueyama wrote:
> > I'm fine, though I don't think I have a right to sign off.
>
> I've just pushed that.
>
> @Rui: Can you please merge the mold counter-part?
I merged the mold counter-part as
https://github.com/rui314/m
I'm fine, though I don't think I have a right to sign off.
On Tue, Jul 12, 2022 at 3:36 PM Martin Liška wrote:
>
> On 7/12/22 08:28, Richard Biener wrote:
> > On Mon, Jul 11, 2022 at 6:35 PM Alexander Monakov
> > wrote:
> >>
> >> On Mon, 11 Jul 2022, Martin Liška wrote:
> >>
> >>> I've clarifie
I updated my code so that it now acquires a lock before calling
claim_file if v0.
https://github.com/rui314/mold/commit/54fedf005fb35acdcb0408395aa403f94262190a
On Mon, Jul 11, 2022 at 8:51 PM Martin Liška wrote:
>
> On 7/11/22 14:24, Rui Ueyama wrote:
> > I updated my patch to support the propos
I updated my patch to support the proposed API:
https://github.com/rui314/mold/commit/22bbfa9bba9beeaf40b76481d175939ee2c62ec8
Martin,
I think you want to apply this patch. Currently, your API always
passes LAPI_V0 as the maximum API version.
diff --git a/lto-plugin/lto-plugin.c b/lto-plugin/lto
On Fri, Jul 8, 2022 at 8:41 PM Alexander Monakov wrote:
>
>
> On Fri, 8 Jul 2022, Martin Liška wrote:
>
> > Hi.
> >
> > All right, there's updated version of the patch that reflects the following
> > suggestions:
> >
> > 1) strings are used for version identification
> > 2) thread-safe API versio
On Mon, Jul 4, 2022 at 10:17 PM Martin Liška wrote:
> On 7/1/22 08:36, Richard Biener wrote:
> > On Thu, Jun 30, 2022 at 10:42 AM Martin Liška wrote:
> >>
> >> On 6/30/22 08:43, Rui Ueyama wrote:
> >>> Thanks Martin for creating this patch.
> >>
> >> You're welcome.
> >>
> >>>
> >>> Here is a pr
Thanks Martin for creating this patch.
Here is a preliminary change for the mold side:
https://github.com/rui314/mold/commit/9ad49d1c556bc963d06cca8233535183490de605
Overall the API is looking fine, though it is not clear what kind of value
is expected as a linker version. A linker version is not
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 are
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 A
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 pers
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 execution
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 fil
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 cleanup_hoo
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, 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 doi
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 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 get_symbol
17 matches
Mail list logo
