llvm dev - Aug 2021 - Resolving a dependency circuit in cmake

+hoy at fb.com <hoy at fb.com> to bring them into the thread

That kind of static function could probably be brought out into a different
library, but I think for this some sort of agreement on the dependency
chains would be really helpful with what each library is bringing to the
table here. It might make more sense for the MC work that's been going on
here to be happening in ProfileData with that depending on Object and MC to
get work done.

Thanks!

-eric

On Mon, Aug 9, 2021 at 2:42 PM Nagurne, James via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
>
>
>
> Some background: our team has added Object to the LINK_COMPONENTS of  the
> ProfileData library as part of work to support code coverage on baremetal
> emebdded devices.
>
> Specifically, there is a new type of InstrProfReader that opens an
> executable and extracts unallocated sections as metadata, rather than
> relying on a heavyweight runtime call and metadata sections living in
> restricted target memory.
>
>
>
> Recently, commit ee7d20e8 (https://reviews.llvm.org/D106861) added a
> dependency on the ProfileData library to the MC library.
>
>
>
> The combination of these changes causes a dependency circuit that results
> in link-time failures:
>
>    - MC depends on ProfileData
>    - ProfileData depends on Object
>    - Object depends on MC
>
>
>
> Is there any good way to resolve such dependency circuits in the build
> system save for an invasive restructuring?
>
>
>
> I’ll note that in the review above, MCPseudoProbe only relies upon the
> static member function FunctionSamples::getCanonicalFnName, which itself
> relies on a number of static data members of FunctionSamples.
>
>
>
> Regards,
>
> J.B. Nagurne
>
> Code Generation
>
> Texas Instruments
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20210809/f4a97de9/attachment.html>

Thanks for the heads-up. The MC work in discussion here deals with metadata on
the binary, while ProfileData mainly deals with a profile without seeing a
binary. Thus I think it would be more appropriate for the MC work to remain in
MC or a third library. The name processing, i.e, calling
`FunctionSamples::getCanonicalFnName` can be  moved into downstream consumer as
a post processing. On the other hand, I’m giving a thought of completely
removing the use of that function, which, if possible, should be the simplest
solution.

+ at Wenlei He<mailto:wenlei at fb.com> @Lei Wang<mailto:wlei at
fb.com>

Thanks,
Hongtao

From: Eric Christopher <echristo at gmail.com>
Date: Monday, August 9, 2021 at 1:05 PM
To: Nagurne, James <j-nagurne at ti.com>, Hongtao Yu <hoy at fb.com>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Resolving a dependency circuit in cmake
+hoy at fb.com<mailto:hoy at fb.com> to bring them into the thread

That kind of static function could probably be brought out into a different
library, but I think for this some sort of agreement on the dependency chains
would be really helpful with what each library is bringing to the table here. It
might make more sense for the MC work that's been going on here to be
happening in ProfileData with that depending on Object and MC to get work done.

Thanks!

-eric

On Mon, Aug 9, 2021 at 2:42 PM Nagurne, James via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hi all,

Some background: our team has added Object to the LINK_COMPONENTS of  the
ProfileData library as part of work to support code coverage on baremetal
emebdded devices.
Specifically, there is a new type of InstrProfReader that opens an executable
and extracts unallocated sections as metadata, rather than relying on a
heavyweight runtime call and metadata sections living in restricted target
memory.

Recently, commit ee7d20e8
(https://reviews.llvm.org/D106861<https://reviews.llvm.org/D106861>) added
a dependency on the ProfileData library to the MC library.

The combination of these changes causes a dependency circuit that results in
link-time failures:

· MC depends on ProfileData

· ProfileData depends on Object

· Object depends on MC

Is there any good way to resolve such dependency circuits in the build system
save for an invasive restructuring?

I’ll note that in the review above, MCPseudoProbe only relies upon the static
member function FunctionSamples::getCanonicalFnName, which itself relies on a
number of static data members of FunctionSamples.

Regards,
J.B. Nagurne
Code Generation
Texas Instruments
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://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/20210809/283863c9/attachment.html>