Re: [FFmpeg-devel] Debug builds and if (ARCH_...) linking issues
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
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
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
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
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
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 short on manpower, this is a very serious issue." The same argument can be used regarding the unwillingness to eliminate DCE. Elimi
Re: [FFmpeg-devel] Debug builds and if (ARCH_...) linking issues
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
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
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 there would be a maintenance issue. That and i have tested it and it works for my situation
Re: [FFmpeg-devel] Debug builds and if (ARCH_...) linking issues
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
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
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
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
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