(2013/11/22 1:47), Ehsan Akhgari wrote:
On 2013-11-21 11:41 AM, ISHIKAWA,chiaki wrote:
(2013/11/15 7:49), Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use
unified builds for C/C++ compilation. The way that unified builds
work is
by using the UNIFIED_SOURCES instead of the SOURCES variable in
moz.build
files. With that, the build system creates files such as:
// Unified_cpp_path_0.cpp
#include "Source1.cpp"
#include "Source2.cpp"
// ...
And compiles them instead of the individual source files.
I just noticed my build locally has started to use unified build.
(I saw files like Unified_*.cpp files being compiled.)
Will this interfere interpreting the backtrace printed by
executable?
For example, this is a real example.
The backtrace of a crash in
https://bugzilla.mozilla.org/show_bug.cgi?id=931642#c87
https://tbpl.mozilla.org/php/getParsedLog.php?id=30894121&tree=Mozilla-Central
showed the following entries.
06:46:12 INFO - 0
XUL!mozilla::storage::Service::Observe(nsISupports*, char const*,
char16_t const*) [nsTArray.h : 871 + 0x0]
06:46:12 INFO - rbx = 0x00007fff74b3f630 r12 =
0x0000000103f088c0
[register dump omitted.]
06:46:12 INFO - Found by: given as instruction pointer in
context
06:46:12 INFO - 1
XUL!_ZThn8_N7mozilla7storage7Service7ObserveEP11nsISupportsPKcPKDs
[Unified_cpp_storage_src1.cpp : 923 + 0x8]
06:46:12 INFO - rbx = 0x0000000000000005 r12 =
0x000000010692b4f8
[register dump omitted.]
06:46:12 INFO - Found by: call frame info
Note the file "Unified_cpp_storage_src1.cpp"
I looked for Unified_cpp_storage_src1.cpp using |mlocate| command under
linux and could not find it. So I thought this file was available only
under OS X (where the bug was reported.)
Only later, looking at this discussion on the mailing list, I realize
that this artificially looking file name is related to Unified Build.
How do people deal with the missing original file name in these dump or
during debugging?
Hmm, I don't understand why you're seeing this. The debug information
should take the original file name, the same way that it does for other
#includes. How do you produce this build?
Well, I don't know exactly, but
https://tbpl.mozilla.org/php/getParsedLog.php?id=30894121&tree=Mozilla-Central
showed at near the top (the second line)
Rev4 MacOSX Lion 10.7 mozilla-central debug test mochitest-5 on
2013-11-21 06:26:17 PST for push 7427eede548f
So this is a standard TBPL test run for MacOSX, I think, so it should
have used typical MacOSX tool chain. Someone in the list surely knows.
(I was asked to look into this bugzilla because a patch that I produced
*seemed* to increase the frequency of this bustage, but I think it is
totally unrelated. The particular bug looks like a MacOS X only thing IMHO.)
PS: Is there a switch to disable Unified Build?
See bug 941097. But for now if you really need it you can manually edit
moz.build files and replace UNIFIED_SOURCES with SOURCES.
If I need the original filename desperately, I would do this.
Mac OS X compiler or whatever tool chain should show the original file
name, indeed in the stack trace. (I don't know how the linux GCC
toolchain handles this. I will find out tomorrow.)
Thank you for the great work increasing the speed of compilation.
Chiaki Ishikawa
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
