Casper Hornstrup wrote:
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Alex Ionescu Sent: 29. maj 2005 20:46 To: ReactOS Development List Subject: Re: [ros-dev] More RBuild issues...
Ge van Geldorp wrote:
From: Casper Hornstrup
Rsym should strip the stabs symbols. What do you need more?
Thinking about it, I believe the difference between the before-rbuild and after-rbuild situation is that before, stabs symbols would be stripped (for both DBG := 0 and 1) but rossym symbols (which make the symbolic stack traceback possible) were only added for DBG := 1. Now, for both DBG := 0 and 1, stabs symbols are stripped but rossym symbols are added even for DBG := 0. Personally I think this is a good thing, as it will allow testers to report meaningfull stack traces.
Testers shouldn't use DBG = 0 builds.... As I've said before...those builds should only be for releasing to the public. They require 64MB of memory to work properly in the first place, are much larger, slower, etc.
I know that Casper (and even myself) want bug reports to be sent with meaningful traces, but a 30MB+ memory/disk bloat is not the way to get that. As I've explained before, since we control the releases, I think it's much better for us to run addr2line. Casper says this will mean having hundreds of copies of the symbol files...but I don't see why. We only need one per release. Then Casper says what about users that compile their own versions. But I've always been told that users DON'T compile their own versions, that only "Developers or testers" do. Well, since I've come to agree with that, then it's clear that there isn't any issue with users compiling their own version of ReactOS. As for testers or developers, there's no point in using the release version, since by building from SVN you're not using a "release" anymore, you're using your own build, which has DBG = 1.
I hope we can find a compromise.
Why do I need to use DBG=1? If developers and testers use DBG=1, who will test DBG=0?
Us, before release. Just like Microsoft tests the "free" build after they are done working with the "Checked one"
People seem to not have a problem allocating 3-4 GB of disk space for their Linux system. Why complain over 30MB?
Because it takes people on 56K modems 4 more hours to download the ISO. Because it makes the installation media much larger; gone is the possibility to give off cool looking ROS CDs on those "business card sized" CDs or other similar media. Because I thought our goal was to give the power of Windows to people that cannot upgrade anymore because of bad hardware. NT4 worked on systems with only 16MB of RAM. Are you saying that we shoudl just scrap that and force everyone to use 64MB? There are even developers among us who have < 64MB PCs...nevermind the companies and people who would love to setup their PC on a system with 32MB of RAM (say an old pentium system). You are scrapping all that away and you still don't understand my point:
After 6 years of looking up symbols in map files, I'm pretty tired of it and now ReactOS can translate the addresses for me. Why would I want to run addr2line for every address?
I *never* said that.
Why would I want to force testers to look them up?
I *never* said that.
Why wouldn't I want ReactOS to submit a bug report containing a stack trace with translated symbols to a mailing list when ReactOS has network capability?
I *never* said that.
The rsym section can be NOLOAD so there is no memory bloat.
Please elaborate...do we support NOLOAD? Is it marked as NOLOAD? I doubt it, because when I boot ReactOS DBG it's using 50MB of memory.
I don't know if you really don't understand what I'm saying, or if you're out of arguments and putting things in my mouth. You're making this seem as if I just said "developers, I've decided that you shall not have symbols anymore!". I am merely pointing out the fact that Windows comes with a clear distinction between a FREE build and a CHECKED build, and that it is senseless to force the CHECKED build down the throat of our users.
Not everyone has a 10MBit connection. Not everyone has a 2GB Dual-Xeon system like you do (or is it Quad?). And not everyone are developers! I asked to find a compromise, because I too do think that it would be nice if user's traces could have the symbols arlready looked up, but killing off the potential market just for that is crazy.
If we've decided overnight that our priority is not deprecated/old hardware support (which I recall is one of the original goals of ReactOS), please let me know, so I can start coding everything in C++/VB, allocate 100MB buffers in non-paged pool, and have everything in usermode use .NET. That's the direction Microsoft is going. Is this what you want our direction to be as well?
I'm merely asking for RELEASE builds to be just that *release* builds. You want them to have symbols built-in the files. I'm saying that it forces *everyone* to have 64MB computers. I'm asking for a compromise in how we can avoid that but still have symbols. I mentionned shipping them externally, or having a system that does it automatically online, or download them online, or have people use addr2line. All these are viable, easy to implement solutions (hint: Microsoft uses all three of them and it works great!). You are unwilling to accept any of those options and simply speak about how "you" will be inconvienced (you still don't understand that you won't, since you'll be using DBG = 1), that is not compromise, that is not diplomacy.
I am going to throw one more solution on the table:
A release+debug symbol build for users which have the necessary hardware and think they will need it.
Best regards, Alex Ionescu