Help needed: building with -finstrument-functions

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Help needed: building with -finstrument-functions

Victor Porof
Hey folks,

I’m trying to build Firefox Desktop with `-finstrument-functions`. End goal is doing some exploratory tracing as part of upcoming browser-architecture efforts.

What’s the appropriate way of doing this?

I tried doing the most naive thing of just passing that flag through CFLAGS and CXXFLAGS with the intention of later linking something like liblttng-ust-cyg-profile via LD_PRELOAD that defines `__cyg_profile_func_enter` and `__cyg_profile_func_exit`. However, `mach build` then results in https://gist.github.com/victorporof/ef17b57b19aa9fdb5a9a3a30eecde2ea (of course).

Any hints?
Victor

_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: Help needed: building with -finstrument-functions

Victor Porof
I’ve linked a prebuilt object that defines `__cyg_profile_func_enter` and `__cyg_profile_func_exit` using LDFLAGS, and that got rid of the initial linker errors. Huzzah!

However, now I’m facing other more concerning linker errors: https://gist.github.com/victorporof/55490f49c7b13b4bcfae10ca4f0c169c

Here’s what I did:

1. Built this simple trace.cpp: https://gist.github.com/victorporof/e9809e33c4dc67ef388672791c4c80cd
- Used `clang++ trace.cpp -mmacosx-version-min=10.9 -c -o trace.o`
- I’m building this without `-finstrument-functions`, obviously.

2. Added the following to my mozconfig:
CFLAGS="-finstrument-functions"
CXXFLAGS="-finstrument-functions"
LDFLAGS="-L[path/to/object] -ltrace.o”

3. `./mach build`
Linker errors galore!

Anything I’m doing wrong?
Victor

> On 10. Nov 2018, at 15:50, David Major <[hidden email]> wrote:
>
> I think you'll have a tough time trying to build any binaries that are
> by nature incomplete without an LD_PRELOAD. You'll have better luck if
> you either properly link your __cyg_profile implementations during the
> build, or link against stubs that you then override with LD_PRELOAD.
>
> Our Windows PGO builds currently use the -finstrument... family in
> order to log function call order. You could probably adapt this by
> removing the WINNT and MOZ_PGO conditions from
> https://searchfox.org/mozilla-central/rev/a3894a4dcfb5d42f2e6eee6cb9faf7141879ef1a/python/mozbuild/mozbuild/frontend/emitter.py#1120
> and https://searchfox.org/mozilla-central/rev/a3894a4dcfb5d42f2e6eee6cb9faf7141879ef1a/mozglue/build/moz.build#41
> .
>
> The limitation of that implementation is that its only instruments
> libxul. This was our way of getting the most bang per buck and
> sidestepping having to deal with all the miscellaneous binaries with
> idiosyncratic build requirements.
>
> Also, if you wait a couple days, I'm sure someone who actually knows
> what they're doing will chime in with a better solution than mine. :)
>
> On Sat, Nov 10, 2018 at 8:57 AM Victor Porof <[hidden email]> wrote:
>>
>> Hey folks,
>>
>> I’m trying to build Firefox Desktop with `-finstrument-functions`. End goal is doing some exploratory tracing as part of upcoming browser-architecture efforts.
>>
>> What’s the appropriate way of doing this?
>>
>> I tried doing the most naive thing of just passing that flag through CFLAGS and CXXFLAGS with the intention of later linking something like liblttng-ust-cyg-profile via LD_PRELOAD that defines `__cyg_profile_func_enter` and `__cyg_profile_func_exit`. However, `mach build` then results in https://gist.github.com/victorporof/ef17b57b19aa9fdb5a9a3a30eecde2ea (of course).
>>
>> Any hints?
>> Victor
>>
>> _______________________________________________
>> dev-builds mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-builds

_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: Help needed: building with -finstrument-functions

Nathan Froyd-5
On Sun, Nov 11, 2018 at 1:25 AM Victor Porof <[hidden email]> wrote:
> 1. Built this simple trace.cpp: https://gist.github.com/victorporof/e9809e33c4dc67ef388672791c4c80cd
> - Used `clang++ trace.cpp -mmacosx-version-min=10.9 -c -o trace.o`
> - I’m building this without `-finstrument-functions`, obviously.
>
> 2. Added the following to my mozconfig:
> CFLAGS="-finstrument-functions"
> CXXFLAGS="-finstrument-functions"
> LDFLAGS="-L[path/to/object] -ltrace.o”

I'll note here that our clang-cl PGO uses
-finstrument-functions-after-inlining instead and that comments around
the tree suggest that bare -finstrument-functions needs some
encouragement to not do bad things:

https://searchfox.org/mozilla-central/source/build/gyp_includes/common.gypi#2616-2619
https://searchfox.org/mozilla-central/source/media/webrtc/trunk/webrtc/build/config/android/BUILD.gn#228-233

I'd try the after-inlining variant and see if that addresses any of
your issues.  A lot of the symbols that are missing look like things
that are probably trivially inlinable.

> 3. `./mach build`
> Linker errors galore!
>
> Anything I’m doing wrong?

Nothing obvious; it looks like you're failing to pick up a bunch of
libc++ symbols, which seems a little peculiar.  I'd suggest diffing:

- config.status from a "clean" objdir and an objdir using your
modified mozconfig, above; and
- backend.mk from dom/media/fake-cdm/ from the same objdirs

(note that you should only need to do `mach configure` to get these
files; there's no need to do a full build)

Those diffs should show if there's anything that might suggest C++
libraries suddenly not getting linked.

-Nathan
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: Help needed: building with -finstrument-functions

Victor Porof

> On 11. Nov 2018, at 20:19, Nathan Froyd <[hidden email]> wrote:
>
> On Sun, Nov 11, 2018 at 1:25 AM Victor Porof <[hidden email]> wrote:
>> 1. Built this simple trace.cpp: https://gist.github.com/victorporof/e9809e33c4dc67ef388672791c4c80cd
>> - Used `clang++ trace.cpp -mmacosx-version-min=10.9 -c -o trace.o`
>> - I’m building this without `-finstrument-functions`, obviously.
>>
>> 2. Added the following to my mozconfig:
>> CFLAGS="-finstrument-functions"
>> CXXFLAGS="-finstrument-functions"
>> LDFLAGS="-L[path/to/object] -ltrace.o”
>
> I'll note here that our clang-cl PGO uses
> -finstrument-functions-after-inlining instead and that comments around
> the tree suggest that bare -finstrument-functions needs some
> encouragement to not do bad things:
>
> https://searchfox.org/mozilla-central/source/build/gyp_includes/common.gypi#2616-2619
> https://searchfox.org/mozilla-central/source/media/webrtc/trunk/webrtc/build/config/android/BUILD.gn#228-233
>
> I'd try the after-inlining variant and see if that addresses any of
> your issues.  A lot of the symbols that are missing look like things
> that are probably trivially inlinable.

Interestingly enough, `-finstrument-functions-after-inlining` did successfully compile, however when running I’m getting a "Couldn't load XPCOM” after a few seconds, no other output other than my printfs. Not sure how I would go about fixing that, any hints?

Besides this, would instrumentation after inlining still notify about the original functions being called, or just about the larger function that they were inlined in? My understanding is the latter, which seems at odds with what I’m after here (unless maybe if I compile without optimizations). Is there a way of getting `__cyg_profile_func_enter` and `__cyg_profile_func_exit` calls regardless of inlining?

>
>> 3. `./mach build`
>> Linker errors galore!
>>
>> Anything I’m doing wrong?
>
> Nothing obvious; it looks like you're failing to pick up a bunch of
> libc++ symbols, which seems a little peculiar.  I'd suggest diffing:
>
> - config.status from a "clean" objdir and an objdir using your
> modified mozconfig, above; and
> - backend.mk from dom/media/fake-cdm/ from the same objdirs
>
> (note that you should only need to do `mach configure` to get these
> files; there's no need to do a full build)
>
> Those diffs should show if there's anything that might suggest C++
> libraries suddenly not getting linked.

Here’s the diff for config.status: https://gist.github.com/victorporof/ff4e25b85358d264a06e0372e1d535fd
Here’s the diff for backend.mk: https://gist.github.com/victorporof/9698bd900b4445b73fdaaaeb88250dcd

They don’t look very telling to me, but I also don’t know what to look for :) Do you see anything?

Thanks for all the tips.
Victor
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds