You might know me as a stout supporter of CMake transition, but a single experience shattered my certainity. Today i tried to resolve a backtrace for a bug report, done with a cmake iso. The results were horrendous. The backtrace was lenghty, but on rbuild such task would take around 15 mintues for me, having all files extracted and prepped log.. At the present moment, cmake bt resolving is a total mess and practically prevents anyone doing such log. I might not be a programmer, but was somewhat skilled in my testers duties, also as some recall, i loved doing manual traces by raddr2line. With cmake - i hate it:
1. the whole process takes minutes more per frame: you need the base address, add the offset and type in the addr2line command 2. base address from kdbg: mod is not reliable, as modules might be relocated. addr2line doesn't know about that... 3. C++ function names are not demangled. For those modules that are written in c++ you will only get source lines, unless you check them up manually. 4. Being somewhat experienced, i see no way how i`m to explain newcomer how to do a backtrace... on the other hand, do you expect anyone to waste half an hour doing so?
This HAS to be resolved before rbuild is put to retirement. Amine was talking about getting back to rsym - sure, why not? Anything that works will be better than current situation.
LOL!
Nothing more to say.
After months you suddenly come up and notice that something doesn't work? Awesome!
Keep it up people, we'll drop rbuild next year.
...
Sure, no problem. Just tell me how to debug explorer on msvc? Oh, no go?
Its up to you, developers. You can do all by yourself and dont need any assistance from others, so why bother that some lousy frames will not be traced? As you can expect that in most cases they wont be. Are you ok with that?
As for months of "not noticing" - you might as well recall that frames in cmake were supposed to be resolved automagically on its own. Where is it then, Timo?
Best regards
On Saturday, October 08, 2011 7:01 PM, "Timo Kreuzer" timo.kreuzer@web.de wrote:
LOL!
Nothing more to say.
After months you suddenly come up and notice that something doesn't work? Awesome!
Keep it up people, we'll drop rbuild next year.
...
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Irony is cool ;)
Seriously all Caemyr's points are valid. We can go to a better debug format anytime, not specifically at the time of cmake switch.
WBR, Aleksey.
On Oct 8, 2011, at 9:09 PM, caemyr@myopera.com wrote:
Sure, no problem. Just tell me how to debug explorer on msvc? Oh, no go?
Its up to you, developers. You can do all by yourself and dont need any assistance from others, so why bother that some lousy frames will not be traced? As you can expect that in most cases they wont be. Are you ok with that?
As for months of "not noticing" - you might as well recall that frames in cmake were supposed to be resolved automagically on its own. Where is it then, Timo?
Best regards
On Saturday, October 08, 2011 7:01 PM, "Timo Kreuzer" timo.kreuzer@web.de wrote:
LOL!
Nothing more to say.
After months you suddenly come up and notice that something doesn't work? Awesome!
Keep it up people, we'll drop rbuild next year.
...
Aleksey Bragin aleksey@reactos.org wrote:
Seriously all Caemyr's points are valid. We can go to a better debug format anytime, not specifically at the time of cmake switch.
Then I hope that Amine's r54055 commit message was a bit ironic and build doesn't really need twice the disk space with RSYM. Because in this case, we get ourselves in another mess and the RAM-Disk on the Debug slave will run out of space.
As the current temporary CMake build is performed on the hard disk while the RBuild one uses the RAM-Disk, you can easily see that the RAM-Disk contributes much to the short build times.
I'm open for any debug format for the CMake switch. I've already made the necessary changes to sysreg2 to first look up the base address with objdump and then use addr2line instead of using just raddr2line in the past. This process is fairly scriptable by the way and this has already been done, see http://svn.reactos.org/svn/reactos/trunk/tools/RosBE-Windows/Root/reladdr2li... Looks like this was from the time when raddr2line also needed the base address.
- Colin
Colin Finck colin@reactos.org wrote:
This process is fairly scriptable by the way and this has already been done, see http://svn.reactos.org/svn/reactos/trunk/tools/RosBE-Windows/Root/reladdr2li...
Correct link: http://svn.reactos.org/svn/reactos/trunk/tools/RosBE-Windows/Root/reladdr2li...
- Colin
On 09/10/2011 13:44, Colin Finck wrote:
Then I hope that Amine's r54055 commit message was a bit ironic and build doesn't really need twice the disk space with RSYM. Because in this case, we get ourselves in another mess and the RAM-Disk on the Debug slave will run out of space.
There was nothing ironic in my commit. Build *does* need twice the disk space with RSYM, simply because RSYM needs stabs debug info.. it can't work with anything else.
Regards, Amine.