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

2017-04-16 Thread Aaron Levinson 

On 4/16/2017 10:08 AM, Ronald S. Bultje wrote:

Hi,

On Sun, Apr 16, 2017 at 12:59 PM, Aaron Levinson 
wrote:


I like using this approach, but I think such files should only be added to
the build if --disable-optimizations is passed into configure.



Or you could detect in configure if the compiler supports DCE?

Ronald


All the compilers that are supported by ffmpeg (including MSVC) 
_already_ support DCE.  They must in order to be able to do any 
successful optimized builds.  So, I think this is really only relevant 
when optimizations are deliberately disabled, and I think it is 
reasonable to expect that DCE will be disabled if optimizations are 
disabled.


Aaron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-04-16 Thread Ronald S. Bultje 
Hi,

On Sun, Apr 16, 2017 at 12:59 PM, Aaron Levinson 
wrote:

> I like using this approach, but I think such files should only be added to
> the build if --disable-optimizations is passed into configure.
>

Or you could detect in configure if the compiler supports DCE?

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-04-16 Thread Aaron Levinson 

On 4/16/2017 8:57 AM, Matt Oliver wrote:

On 14 April 2017 at 08:05, Hendrik Leppkes  wrote:


On Fri, Apr 14, 2017 at 12:00 AM, Ronald S. Bultje 
wrote:

Hi Aaron,

On Thu, Apr 13, 2017 at 4:47 PM, Aaron Levinson 
wrote:


#if ARCH_AARCH64
if (ARCH_AARCH64)
return ff_get_cpu_flags_aarch64();
#endif



If you add #if, at least replace the if with it. #if + if is redundant.



Such a script could be reviewed and checked into the source base, then
applied to the source base, and possibly reused in the future as

necessary.



Why not use the script as a preprocessor during compilation? We did that
for pre-2013 MSVC compilation and that worked """fine""".

Or why not ask Microsoft to add a CLI option to cl.exe for enabling DCE

but

otherwise disabling optimizations? All other compilers seem capable of
this, so it's odd to see that big Microsoft is incompetent whereas a

bunch

of opensource hippies could do the same 10+ yrs ago.



Its not a MSVC-exclusive problem. Many compilers don't perform DCE in
full debug builds, which are as such not possible with ffmpeg, making
debuging sometimes a bit annoying when a bunch of variables are
optimized out and stuff gets inlined.



Unfortunately writing a script is a rather complex task as there are many
DCE blocks that are actually generated by macro expansion and various
pre-processor trickery (swresample is full of this sort of stuff). Combine
that with DCE blocks being nested within each other and it becomes a rather
complex task to find them all. Much more complex than what a simple regex
script can handle.

If people object to changing the current code base then the only solution
would be a program/script that can generate some empty definitions for all
the functions/variables that are used in DCE blocks so as to avoid the
errors about them not existing. These empty definitions would have to be
maintained in a set of external files or generated at compile time.

There are actually a considerable number of missing funcs/vars used in DCE
blocks. As an example i have attached a list of empty funcs/vars that I
have been able to programmatically detect (there are a lot! and i may have
missed some).


I like using this approach, but I think such files should only be added 
to the build if --disable-optimizations is passed into configure.  I 
think that's the sort of approach that most people could get behind 
since it won't affect the regular build.  I think it is okay if these .c 
files aren't perfect from the start, and while it would be nice if 
people that add new functions (or change existing function definitions) 
to arch (or similar) were to make appropriate changes to these files, if 
they don't, that's okay too.  There are likely a limited number of 
people that would choose to employ --disable-optimizations, and it is 
not a big deal to add a function or two to these files as they crop up 
and submit a patch for the changes.


Aaron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-04-13 Thread Hendrik Leppkes 
On Fri, Apr 14, 2017 at 12:00 AM, Ronald S. Bultje  wrote:
> Hi Aaron,
>
> On Thu, Apr 13, 2017 at 4:47 PM, Aaron Levinson 
> wrote:
>
>> #if ARCH_AARCH64
>> if (ARCH_AARCH64)
>> return ff_get_cpu_flags_aarch64();
>> #endif
>>
>
> If you add #if, at least replace the if with it. #if + if is redundant.
>
>
>> Such a script could be reviewed and checked into the source base, then
>> applied to the source base, and possibly reused in the future as necessary.
>
>
> Why not use the script as a preprocessor during compilation? We did that
> for pre-2013 MSVC compilation and that worked """fine""".
>
> Or why not ask Microsoft to add a CLI option to cl.exe for enabling DCE but
> otherwise disabling optimizations? All other compilers seem capable of
> this, so it's odd to see that big Microsoft is incompetent whereas a bunch
> of opensource hippies could do the same 10+ yrs ago.
>

Its not a MSVC-exclusive problem. Many compilers don't perform DCE in
full debug builds, which are as such not possible with ffmpeg, making
debuging sometimes a bit annoying when a bunch of variables are
optimized out and stuff gets inlined.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-04-13 Thread Ronald S. Bultje 
Hi Aaron,

On Thu, Apr 13, 2017 at 4:47 PM, Aaron Levinson 
wrote:

> #if ARCH_AARCH64
> if (ARCH_AARCH64)
> return ff_get_cpu_flags_aarch64();
> #endif
>

If you add #if, at least replace the if with it. #if + if is redundant.


> Such a script could be reviewed and checked into the source base, then
> applied to the source base, and possibly reused in the future as necessary.


Why not use the script as a preprocessor during compilation? We did that
for pre-2013 MSVC compilation and that worked """fine""".

Or why not ask Microsoft to add a CLI option to cl.exe for enabling DCE but
otherwise disabling optimizations? All other compilers seem capable of
this, so it's odd to see that big Microsoft is incompetent whereas a bunch
of opensource hippies could do the same 10+ yrs ago.

I have no opinion on #if vs. if, but I generally prefer to keep things as
they are. I'll follow whatever the rest of the code uses, and right now we
use if+DCE so I'll continue to use that.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-04-13 Thread Aaron Levinson 

On 4/13/2017 11:04 AM, Matt Oliver wrote:

On 14 April 2017 at 03:31, Hendrik Leppkes  wrote:


On Thu, Apr 13, 2017 at 7:16 PM, Matt Oliver  wrote:

On 14 April 2017 at 02:11, Rostislav Pehlivanov 

wrote:





On 13 April 2017 at 16:51, wm4  wrote:


On Thu, 13 Apr 2017 17:39:57 +1000
Matt Oliver  wrote:


On 13 April 2017 at 17:20, Aaron Levinson 

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.




I wouldn't like any weird hacks in the source just to work-around the
lack of DCE in debug builds, so we should decide to either keep using
it or get rid of it.



I agree.


It seems that the DCE requirement affects debug builds in general, and 
not just with Windows builds.  And, because of the DCE requirement, it 
is necessary to introduce some level of optimization in debug builds, 
which makes it harder to debug.  Sure, I can use -Zo with MSVC on 
Windows (see https://msdn.microsoft.com/en-us/library/dn785163.aspx for 
more details) to make it easier to debug release builds, but that's not 
the same as debugging a fully debug build, and something similar may not 
exist with other compilers.


I reviewed the thread mentioned by Matt Oliver above, and one of the 
arguments against removing DCE was that it may make some people less 
likely to work on the project.  Nicolas George wrote:


"Someone's personal preferences affect their willingness to work on the
project. Since the project is perpetually

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

2017-04-13 Thread Matt Oliver 
On 14 April 2017 at 03:31, Hendrik Leppkes  wrote:

> On Thu, Apr 13, 2017 at 7:16 PM, Matt Oliver  wrote:
> > On 14 April 2017 at 02:11, Rostislav Pehlivanov 
> wrote:
> >
> >>
> >>
> >> On 13 April 2017 at 16:51, wm4  wrote:
> >>
> >>> On Thu, 13 Apr 2017 17:39:57 +1000
> >>> Matt Oliver  wrote:
> >>>
> >>> > On 13 April 2017 at 17:20, Aaron Levinson 
> 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.
> >
>
> I wouldn't like any weird hacks in the source just to work-around the
> lack of DCE in debug builds, so we should decide to either keep using
> it or get rid of it.


I agree.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-04-13 Thread Hendrik Leppkes 
On Thu, Apr 13, 2017 at 7:16 PM, Matt Oliver  wrote:
> On 14 April 2017 at 02:11, Rostislav Pehlivanov  wrote:
>
>>
>>
>> On 13 April 2017 at 16:51, wm4  wrote:
>>
>>> On Thu, 13 Apr 2017 17:39:57 +1000
>>> Matt Oliver  wrote:
>>>
>>> > On 13 April 2017 at 17:20, Aaron Levinson  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.
>

I wouldn't like any weird hacks in the source just to work-around the
lack of DCE in debug builds, so we should decide to either keep using
it or get rid of it.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-04-13 Thread Matt Oliver 
On 14 April 2017 at 02:11, Rostislav Pehlivanov  wrote:

>
>
> On 13 April 2017 at 16:51, wm4  wrote:
>
>> On Thu, 13 Apr 2017 17:39:57 +1000
>> Matt Oliver  wrote:
>>
>> > On 13 April 2017 at 17:20, Aaron Levinson  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

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

2017-04-13 Thread Rostislav Pehlivanov 
On 13 April 2017 at 16:51, wm4  wrote:

> On Thu, 13 Apr 2017 17:39:57 +1000
> Matt Oliver  wrote:
>
> > On 13 April 2017 at 17:20, Aaron Levinson  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.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

CCing him because its been 4 months

btw how would the GCC pragma approach work?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-04-13 Thread wm4 
On Thu, 13 Apr 2017 17:39:57 +1000
Matt Oliver  wrote:

> On 13 April 2017 at 17:20, Aaron Levinson  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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-04-13 Thread Matt Oliver 
On 13 April 2017 at 17:20, Aaron Levinson  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).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-04-13 Thread Hendrik Leppkes 
On Thu, Apr 13, 2017 at 9:20 AM, Aaron Levinson  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.
>

We require Dead-Code-Eliminiation to be performed at all times in a
FFmpeg build, so your compiler needs to do this for a build to
succeed.
You can find the reasonings and discussions about this in the Mailing
List archives, it comes up once in a while.

If you are actually working on some code, I can only recommend to use
the pragma in the files you are working on. Its not that bad, really.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-04-13 Thread Aaron Levinson 
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.


Thanks,
Aaron Levinson
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel