|
|
Created:
6 years, 9 months ago by mithro-old Modified:
6 years, 3 months ago CC:
chromium-reviews Base URL:
https://chromium.googlesource.com/chromium/src.git@master Visibility:
Public. |
DescriptionEnable debugging symbols to always use DWARF-4 format.
Adding -gdwarf-4 to make DWARF-4 the output format.
* gcc 4.6 outputs DWARF-2 by default
* gcc 4.7 outputs DWARF-4 by default
* clang <3.4 outputs DWARF-3 by default
* clang >3.4 outputs DWARF-4 by default
DWARF-4 is the latest debug output format which includes features for
macro-expansion, better var tracking and other similar options.
From http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
> -gdwarf-4
> Produce debugging information in DWARF format (if that is
> supported). The value of version may be either 2, 3 or 4; the
> default version for most targets is 4. Note that with DWARF
> Version 2, some ports require and always use some non-conflicting
> DWARF 3 extensions in the unwind tables.
>
> Version 4 may require GDB 7.0 and -fvar-tracking-assignments for
> maximum benefit.
BUG=
Committed: https://crrev.com/fb34b348eead98f521ea76b3645fe09da8f1f868
Cr-Commit-Position: refs/heads/master@{#295933}
Patch Set 1 #Patch Set 2 : Fixing clang. #Patch Set 3 : Removing -fvar-tracking-* flags for now. #
Total comments: 4
Patch Set 4 : Fixing for code review comments. #Patch Set 5 : Rebase onto master. #Patch Set 6 : Rebase onto master. #Patch Set 7 : Rebasing onto master. #Patch Set 8 : Rebasing onto master. #Patch Set 9 : Removing the extra debugging support and just enabling dwarf-4 format. #Patch Set 10 : Rebase onto master. #Messages
Total messages: 29 (1 generated)
Hi, I was unsure who to send this too and "git cl owners" didn't suggest anyone. You people seem to have had some involvement with this file, so do you think you can review it? I've had this change floating around in my local client for 6 months now and found it very useful when debugging crashes, particularly crashes inside gtest unit tests which use lots of macros. This does make the debug binary bigger, so it might have to wait till https://code.google.com/p/chromium/issues/detail?id=352046 -- "Enable debug symbols fission for Chrome Debug builds" is finished. Tim
mmoss will know if there are any important size limitations to be concerned about, for example, on debug bots. https://codereview.chromium.org/198363002/diff/40001/build/common.gypi File build/common.gypi (right): https://codereview.chromium.org/198363002/diff/40001/build/common.gypi#newcod... build/common.gypi:3046: '-g3', '-gdwarf-4', These are separate options, can you put them on separate lines? https://codereview.chromium.org/198363002/diff/40001/build/common.gypi#newcod... build/common.gypi:3046: '-g3', '-gdwarf-4', How do you expect this to interact with the “fastbuild” option?
On 2014/03/13 13:12:03, Mark Mentovai wrote: > mmoss will know if there are any important size limitations to be concerned > about, for example, on debug bots. We've already hit size issues on 32-bit official builds, when trying to strip symbols from some binaries, but we've worked around it by using a custom eu-strip on those bots. I think that should also handle any bloat caused by this. I'm not aware of any other concerns.
+thestig in case he is aware of other issues
Do you know the affect on build time / build output size? On Ubuntu Precise, the default -gdwarf-version is -gdwarf-2, BTW.
On 2014/03/13 19:43:03, Lei Zhang wrote: > Do you know the affect on build time / build output size? Seems to have no measurable effect on build time, but does seems to increase linking time slightly (about 3-5%). I'm also seeing about a 3% increase in output size. These numbers are all on a z620, so they could just be noise? > On Ubuntu Precise, the default -gdwarf-version is -gdwarf-2, BTW. Looks like you are correct, I was reading the gcc 4.7 documentation. gcc 4.6 outputs DWARF-2 by default gcc 4.7 outputs DWARF-4 by default clang <3.4 outputs DWARF-3 by default clang >3.4 outputs DWARF-4 by default
On 2014/03/13 15:00:44, mmoss wrote: > On 2014/03/13 13:12:03, Mark Mentovai wrote: > > mmoss will know if there are any important size limitations to be concerned > > about, for example, on debug bots. > > We've already hit size issues on 32-bit official builds, when trying to strip > symbols from some binaries, but we've worked around it by using a custom > eu-strip on those bots. I think that should also handle any bloat caused by > this. I'm not aware of any other concerns. FYI mmoss, on a related note I also have CLs to enable experimental debug fission that should make 32-bit debug builds significantly smaller. Take a look at https://code.google.com/p/chromium/issues/detail?id=352046 and https://codereview.chromium.org/197013010
https://codereview.chromium.org/198363002/diff/40001/build/common.gypi File build/common.gypi (right): https://codereview.chromium.org/198363002/diff/40001/build/common.gypi#newcod... build/common.gypi:3046: '-g3', '-gdwarf-4', On 2014/03/13 13:12:04, Mark Mentovai wrote: > These are separate options, can you put them on separate lines? Done. https://codereview.chromium.org/198363002/diff/40001/build/common.gypi#newcod... build/common.gypi:3046: '-g3', '-gdwarf-4', On 2014/03/13 13:12:04, Mark Mentovai wrote: > How do you expect this to interact with the “fastbuild” option? Changed -g3 to be conditional on fastbuild==X.
On 2014/03/16 11:09:43, mithro wrote: > https://codereview.chromium.org/198363002/diff/40001/build/common.gypi > File build/common.gypi (right): > > https://codereview.chromium.org/198363002/diff/40001/build/common.gypi#newcod... > build/common.gypi:3046: '-g3', '-gdwarf-4', > On 2014/03/13 13:12:04, Mark Mentovai wrote: > > These are separate options, can you put them on separate lines? > > Done. > > https://codereview.chromium.org/198363002/diff/40001/build/common.gypi#newcod... > build/common.gypi:3046: '-g3', '-gdwarf-4', > On 2014/03/13 13:12:04, Mark Mentovai wrote: > > How do you expect this to interact with the “fastbuild” option? > > Changed -g3 to be conditional on fastbuild==X. Friendly poke...
Not sure who you are poking exactly, but lgtm. I think CrOS should be ok too, as they are likely ahead of Ubuntu Precise on g++ versions.
On 2014/03/18 02:52:43, Lei Zhang wrote: > Not sure who you are poking exactly, but lgtm. > > I think CrOS should be ok too, as they are likely ahead of Ubuntu Precise on g++ > versions. If there are no objections, I'll land this patch late tomorrow my time.
LGTM
The CQ bit was checked by mithro@mithis.com
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/mithro@mithis.com/198363002/90001
The CQ bit was unchecked by commit-bot@chromium.org
Retried try job too often on win_rel for step(s) net_unittests http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...
The CQ bit was checked by mithro@mithis.com
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/mithro@mithis.com/198363002/90001
Message was sent while issue was closed.
Change committed as 257944
Message was sent while issue was closed.
A revert of this CL has been created in https://codereview.chromium.org/203683007/ by pneubeck@chromium.org. The reason for reverting is: Might be the cause for memory exhaustion during compilation on the Linux dbg build bot: http://build.chromium.org/p/chromium.linux/buildstatus?builder=Linux%20Builde....
The CQ bit was checked by mithro@mithis.com
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/mithro@mithis.com/198363002/130001
FYI, CQ is re-trying this CL (attempt #1). The failing builders are: android_dbg_triggered_tests on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/android_dbg_triggered...)
Message was sent while issue was closed.
Change committed as 280980
Message was sent while issue was closed.
A revert of this CL has been created in https://codereview.chromium.org/366963002/ by jochen@chromium.org. The reason for reverting is: Linux dbg builder runs out of memory.
The CQ bit was checked by mithro@mithis.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/198363002/170001
Message was sent while issue was closed.
Committed patchset #10 (id:170001) as 1d869328374b966bf4e5b8485342ba547f524057
Message was sent while issue was closed.
Patchset 10 (id:??) landed as https://crrev.com/fb34b348eead98f521ea76b3645fe09da8f1f868 Cr-Commit-Position: refs/heads/master@{#295933} |