[FFmpeg-devel] Debug builds and if (ARCH_...) linking issues

[Matt Oliver]

On 14 April 2017 at 02:11, Rostislav Pehlivanov <atomnuker at gmail.com> wrote:

>
>
> On 13 April 2017 at 16:51, wm4 <nfxjfg at googlemail.com> wrote:
>
>> On Thu, 13 Apr 2017 17:39:57 +1000
>> Matt Oliver <protogonoi at gmail.com> wrote:
>>
>> > On 13 April 2017 at 17:20, Aaron Levinson <alevinsn at aracnet.com> wrote:
>> >
>> > > I wanted to build a debug build of ffmpeg using Visual C++ today, one
>> > > without any optimizations.  This implies the use of the -Od compiler
>> > > option.  Unfortunately, I quickly discovered that the build fails soon
>> > > after it starts because it can't find certain architecture-specific
>> > > references.  For example, in libavutil/cpu.c, there is the following:
>> > >
>> > >     if (ARCH_AARCH64)
>> > >         return ff_get_cpu_flags_aarch64();
>> > >
>> > > The linker couldn't find ff_get_cpu_flags_aarch64 (and other similar
>> > > references) and failed.  This isn't an issue when optimizations are
>> turned
>> > > on because the compiler notices that ARCH_AARCH64 is defined as 0 and
>> > > eliminates the relevant code.
>> > >
>> > > Effectively, successful builds of ffmpeg depend on this compiler
>> > > optimization.  This appears to have been the standard practice in the
>> > > ffmpeg code base for at least the last few years, but it is unclear
>> to me
>> > > why this approach is being used, since, in addition to depending on
>> > > specific compiler behavior, it prevents fully debug builds from
>> succeeding,
>> > > at least with Visual C++.
>> > >
>> > > If people like the if (ARCH_...) syntax, while it wouldn't look quite
>> as
>> > > nice, what's wrong with doing the following:
>> > >
>> > > #if ARCH_AARCH64
>> > >     if (ARCH_AARCH64)
>> > >         return ff_get_cpu_flags_aarch64();
>> > > #endif
>> > >
>> > > Another, much less desirable option is to use #pragma optimize for the
>> > > relevant functions in ffmpeg to turn optimizations on for specific
>> > > functions.
>> > >
>> > > A third option would be to build only the relevant files with
>> > > optimizations turned on, but this will end up making the Makefiles
>> more
>> > > complicated, and the relative simplicity of the Makefiles is
>> appealing.
>> > >
>> > > For now, I'm using both -Od and -Og with Visual C++ (-Og turns on some
>> > > optimizations, but not as much as -O1 or -O2), but this isn't the
>> same as a
>> > > true debug build.
>> > >
>> >
>> > Similar patches have been submitted before. This is an issue with Dead
>> Code
>> > Elimination (DCE) within FFmpeg and the fact the MSVC doesn't support
>> > removing it in debug builds.
>> >
>> > There have been some discussions on the mailing list in the past about
>> > resolving this but nothing was ever decided.
>> >
>> > As a quick and dirty work around I have a tool that i wrote that scans
>> in
>> > the configure/makefile from a ffmpeg distro and generates a native
>> Visual
>> > Studio project file that can be used to just compile within Visual
>> Studio
>> > itself. You just pass it the desired configure options that you want to
>> use
>> > to build the project and it will make one for you. The main thing is
>> that
>> > it scans the source and automatically generates the missing DCE sections
>> > and adds them so that everything will compile correctly with Debug
>> builds
>> > and you can debug directly in VS. You can find the tool here
>> > http://shiftmediaproject.github.io/1-projects/ (normally i wouldn't put
>> > external references on the mailing list but this may be of use to you).
>>
>> Any chance you could revive your old patches to remove the DCE
>> requirement? (Not sure if there were any patches.)
>>
>> Before you do any real work, make a thread on the ML requesting
>> comments on this. Although I would very much welcome such patches, I'm
>> not fully sure about others.
>>
>> This DCE requirement is pretty painful, and affects debugging on Linux
>> as well.
>>
>
I put up a general discussion a while ago (
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/204530.html) but
there were a few people who opposed a direct removal of DCE and no one
really came up with a consensus as to what the acceptable approach would be.

It also needed to be decided whether there would be a complete removal of
DCE or just removing the occurrences that caused linker errors (see
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/204811.html for my
previous example). Either approach can be done but there are a lot of
changes that would result so i didn't write up any patches until some sort
of decision could be made as to what the accepted approach would be (which
never happened).

So instead i wrote the previously mentioned tool that scans the source code
and generates empty function definitions and variable definitions for
anything used in a DCE block and spits them out to a code file. The output
from this may be of some use but the program is windows only (it uses msvc
to pass the files) and has to be manually run so after the initial output
there would be a maintenance issue. That and i have tested it and it works
for my situation but there are so many complex combinations of DCE blocks
that i cant guarantee it picks them all up correctly.

So I have no issue in fixing the DCE issues but i cant fix them if no one
will let me ;)