1) -j2 still doesn't work. It's giving me issues when compiling wininet's resources. Almost as if it's trying to compile them before parsing them or something similar:
Alex_Ionescu|DND wininet.rci.tmp:178:10: Error: Unexpected end of file during preprocessing Alex_Ionescu|DND make: *** [obj-i386/lib/wininet/version.coff] Error 1 Alex_Ionescu|DND make: *** Waiting for unfinished jobs.... Alex_Ionescu|DND make: *** Waiting for unfinished jobs.... Alex_Ionescu|DND lib/wininet/version.rc:31:13: Error: Cannot open file LONG Alex_Ionescu|DND make: *** [obj-i386/lib/wininet/rsrc.coff] Error 1
Not using -j2 fixes this.
2) Can't boot ROS, whether or not dbg 1 or 0 is used.
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Alex Ionescu Sent: 29. maj 2005 01:40 To: ReactOS Development List Subject: [ros-dev] More RBuild issues...
- -j2 still doesn't work. It's giving me issues when compiling
wininet's resources. Almost as if it's trying to compile them before parsing them or something similar:
Alex_Ionescu|DND wininet.rci.tmp:178:10: Error: Unexpected end of file during preprocessing Alex_Ionescu|DND make: *** [obj-i386/lib/wininet/version.coff] Error 1 Alex_Ionescu|DND make: *** Waiting for unfinished jobs.... Alex_Ionescu|DND make: *** Waiting for unfinished jobs.... Alex_Ionescu|DND lib/wininet/version.rc:31:13: Error: Cannot open file LONG Alex_Ionescu|DND make: *** [obj-i386/lib/wininet/rsrc.coff] Error 1
Not using -j2 fixes this.
I'll look at this.
- Can't boot ROS, whether or not dbg 1 or 0 is used.
Revision 15583 (point of merge) both boots and installs so it is a change after the merge that has broken it if it doesn't boot now.
Casper
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Alex Ionescu Sent: 29. maj 2005 01:40 To: ReactOS Development List Subject: [ros-dev] More RBuild issues...
- Can't boot ROS, whether or not dbg 1 or 0 is used.
I just built, installed, and booted revision 15650 just fine. I use GCC 3.4.2.
Let me just say that I'm increasingly annoyed by the way you "fix" things. Revision 15583 both builds (at least with GCC 3.4.2), installs and boots. Then you enable optimizations in revision 15588 and 15589 even though I told you that it would cause build errors. Of course you didn't even try to build or boot ReactOS before you committed that change so you spend the next 6 commits (15588, 15589, 15633, 15641, 15642, 15645) (+ filips 15600) making ReactOS build again. I will accept responsibility for disabling optimizations, but I WILL NOT accept responsibility for the breakage you've caused by enabling optimizations.
Casper
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 01:40 To: ReactOS Development List Subject: [ros-dev] More RBuild issues...
- Can't boot ROS, whether or not dbg 1 or 0 is used.
I just built, installed, and booted revision 15650 just fine. I use GCC 3.4.2.
Let me just say that I'm increasingly annoyed by the way you "fix" things. Revision 15583 both builds (at least with GCC 3.4.2), installs and boots. Then you enable optimizations in revision 15588 and 15589 even though I told you that it would cause build errors. Of course you didn't even try to build or boot ReactOS before you committed that change so you spend the next 6 commits (15588, 15589, 15633, 15641, 15642, 15645) (+ filips 15600) making ReactOS build again. I will accept responsibility for disabling optimizations, but I WILL NOT accept responsibility for the breakage you've caused by enabling optimizations.
I did not break anything, I merely fixed what was already broken. You merged a crippled build system which could not build optimizations, which is something we've done for ages. And I wasted my developer time to fix that. I've already told you that I cannot boot the DBG = 1 build either, so it has nothing to do with optimizations.
If anyone has the right to be annoyed, it's the developers, who since yesterday, have been:
1) Fixing rbuild bugs (unrelated to optimizations) 2) Unable to boot ROS 3) Fixing GCC 4.0 bugs.
I know a minority have these issues, but a minority had GDB bugs too when I broke it. And I took responsability for that. You can't outright REMOVE features and then say "well Alex, it's your fault for adding them back!".
Let's not mention the fact that almost all my release features have been outright removed from rbuild, as if my work on them didn't even matter.
Casper
Best regards, Alex Ionescu
From: Alex Ionescu
If anyone has the right to be annoyed, it's the developers, who since yesterday, have been:
- Fixing rbuild bugs (unrelated to optimizations)
- Unable to boot ROS
- Fixing GCC 4.0 bugs.
It's not like you were unaware that the rbuild changes were coming. Casper has asked repeatedly for people to try it out and give feedback. My personal experience is that Casper was very responsive to feedback.
Gé van Geldorp.
Ge van Geldorp wrote:
It's not like you were unaware that the rbuild changes were coming. Casper has asked repeatedly for people to try it out and give feedback. My personal experience is that Casper was very responsive to feedback.
I agree. I don't blame anyone for the latest breakages. rbuild is a nice enhancement for our build system, we've had many more severe breakages caused by much smaller changes and only few people cared about them being fixed as fast as possible. We should just be patient, just like when we switched from CVS to SVN ;)
Best Regards Thomas
Thomas Weidenmueller wrote:
Ge van Geldorp wrote:
It's not like you were unaware that the rbuild changes were coming. Casper has asked repeatedly for people to try it out and give feedback. My personal experience is that Casper was very responsive to feedback.
I agree. I don't blame anyone for the latest breakages. rbuild is a nice enhancement for our build system, we've had many more severe breakages caused by much smaller changes and only few people cared about them being fixed as fast as possible. We should just be patient, just like when we switched from CVS to SVN ;)
Then I can only hope I will be granted the same patience with the new headers and tree structure.
Best Regards Thomas
Best regards, Alex Ionescu
Ge van Geldorp wrote:
From: Alex Ionescu
If anyone has the right to be annoyed, it's the developers, who since yesterday, have been:
- Fixing rbuild bugs (unrelated to optimizations)
- Unable to boot ROS
- Fixing GCC 4.0 bugs.
It's not like you were unaware that the rbuild changes were coming. Casper has asked repeatedly for people to try it out and give feedback. My personal experience is that Casper was very responsive to feedback.
He is, and I haven't denied this.
Gé van Geldorp.
Best regards, Alex Ionescu
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Alex Ionescu Sent: 29. maj 2005 16:53 To: ReactOS Development List Subject: Re: [ros-dev] More RBuild issues...
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 01:40 To: ReactOS Development List Subject: [ros-dev] More RBuild issues...
I did not break anything, I merely fixed what was already broken. You merged a crippled build system which could not build optimizations, which is something we've done for ages. And I wasted my developer time to fix that. I've already told you that I cannot boot the DBG = 1 build either, so it has nothing to do with optimizations.
It may be crippled without optimizations but it is hardly anything that will kill anyone so I decided it was better to merge it to trunk now (and add support for optimization later) since I could find some time to merge this weekend. We've hacked on the old build system for 3-4 years now. It would be impossible for me to implement all features of the old build system (nor would we want to IMHO).
If we didn't have so many build tool configurations then I didn't have to make sure it would work in so many configurations. I really wish we had a standard build tool configuration. If we use the same configuration then there is a much higher chance it will work for all. If you had told me it didn't work in your particular configuration within the last 5 months then I would have made sure it would work if I could.
If anyone has the right to be annoyed, it's the developers, who since yesterday, have been:
- Fixing rbuild bugs (unrelated to optimizations)
I would like it if you could post revision numbers of these bugfixes because you make it sound like there are a million of them. I know that 'make install' installs some files to the wrong folders and some files are not installed. Please list the rest of the issues you believe are bugs. The patch is 2MB and very intrusive so I don't think you can reasonably expect there to not be any bugs.
- Unable to boot ROS
You haven't even posted your configuration yet. Do you think I'm psychic?
- Fixing GCC 4.0 bugs.
Since when is there a rule that says you must test your changes with GCC 4?
I know a minority have these issues, but a minority had GDB bugs too when I broke it. And I took responsability for that. You can't outright REMOVE features and then say "well Alex, it's your fault for adding them back!".
I would have implemented it after the merge.
Let's not mention the fact that almost all my release features have been outright removed from rbuild, as if my work on them didn't even matter.
Why didn't you say which features you wanted ported?
Casper
Casper Hornstrup wrote:
It may be crippled without optimizations but it is hardly anything that will kill anyone so I decided it was better to merge it to trunk now (and add support for optimization later) since I could find some time to merge this weekend. We've hacked on the old build system for 3-4 years now. It would be impossible for me to implement all features of the old build system (nor would we want to IMHO).
If we didn't have so many build tool configurations then I didn't have to make sure it would work in so many configurations. I really wish we had a standard build tool configuration. If we use the same configuration then there is a much higher chance it will work for all. If you had told me it didn't work in your particular configuration within the last 5 months then I would have made sure it would work if I could.
I know, and I should've taken a look at the branch earlier... I apologize. You'be been a great listener.
I would like it if you could post revision numbers of these bugfixes because you make it sound like there are a million of them. I know that 'make install' installs some files to the wrong folders and some files are not installed. Please list the rest of the issues you believe are bugs. The patch is 2MB and very intrusive so I don't think you can reasonably expect there to not be any bugs.
Almost everything after the merge are fixes :)
- Unable to boot ROS
You haven't even posted your configuration yet. Do you think I'm psychic?
I'm sorry...in any case...both me and Filip can boot now..thank you.
- Fixing GCC 4.0 bugs.
Since when is there a rule that says you must test your changes with GCC 4?
Good point, but even 3.4.3 is broken....well, not after my "annoying" fixes...
I know a minority have these issues, but a minority had GDB bugs too when I broke it. And I took responsability for that. You can't outright REMOVE features and then say "well Alex, it's your fault for adding them back!".
I would have implemented it after the merge.
Let's not mention the fact that almost all my release features have been outright removed from rbuild, as if my work on them didn't even matter.
Why didn't you say which features you wanted ported?
Casper
I think I've been too harsh lately but I hope you can understand.. I'm not blaming this entirely on you and I know everythign comes with issues...I think it's natural for me to complain about them. I'm only pissed about optimizations not working (but I'll test again), but I can understand that it was better to merge into trunk and have it fixed there, isntead of delaying rbuild even more then it already has.
So in essence and to end this discussion I'd like to say that I really really appreciate the work you (and the others) have done on rbuild and I very much value your profesionalism and feedback/responsiveness on the issues. I can also boot/build ReactOS on GCC 4.0 so that also makes me happy.
I can only hope that you will have time to implement project linker-flags like I mentionned and add back the strip functionality :) Oh and, it seems that "make module_install" doesn't rebuild the module (even though I modified files). It would be good if this could be fixed. And putting the makefiles into svn:ignore.
Best regards, Alex Ionescu
I can only hope that you will have time to implement project linker-flags like I mentionned and add back the strip functionality :) Oh and, it seems that "make module_install" doesn't rebuild the module (even though I modified files). It would be good if this could be fixed. And putting the makefiles into svn:ignore.
Please describe it here: http://reactos.com/wiki/index.php/Xmlbuildsystem
Rsym should strip the stabs symbols. What do you need more?
Casper
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.
Ge van Geldorp.
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.
Ge van Geldorp.
Best regards, Alex Ionescu
-----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?
People seem to not have a problem allocating 3-4 GB of disk space for their Linux system. Why complain over 30MB? 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? Why would I want to force testers to look them up? 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? The rsym section can be NOLOAD so there is no memory bloat.
Casper
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
From: Alex Ionescu
Because it takes people on 56K modems 4 more hours to download the ISO.
Call me spoiled, but I don't think we should limit ourselves by the possibilities of 56K modems.
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.
Right... How many of these have we given away?
The rsym section can be NOLOAD so there is no memory bloat.
Please elaborate...do we support NOLOAD?
Yes
Is it marked as NOLOAD?
Yes
I doubt it, because when I boot ReactOS DBG it's using 50MB of memory.
That's because the symbol handling code now goes in and reads the rossym section. It's not the loader, it's the symbol handling code.
I'm merely asking for RELEASE builds to be just that *release* builds.
And that sounds reasonable when we get at ReactOS 1.0. Until that time, the more debug info available, the better.
You want them to have symbols built-in the files. I'm saying that it forces *everyone* to have 64MB computers.
No, it doesn't. There's a difference between including the symbols in the files and loading them into memory.
Gé van Geldorp
I just want to point out that thunk/posix, trunk/os2, trunk/vms and rosapps are still using the old build system.
Maarten Bosma
Hartmut Birr wrote:
Alex Ionescu wrote:
Because it takes people on 56K modems 4 more hours to download the ISO.
It make no sense to discuss about the download time. The difference between both iso images is 1.3MB (10,762/12,078kB).
FWIW, 1.3MB = appx 7 minutes download time on my 26k connection.
Royce Mitchell III wrote:
Hartmut Birr wrote:
It make no sense to discuss about the download time. The difference between both iso images is 1.3MB (10,762/12,078kB).
FWIW, 1.3MB = appx 7 minutes download time on my 26k connection.
If you have really a 26k connection, it needs 9.5 minutes more. If you are patient enough to wait 76 minutes you are also a patient to wait 85 minutes. In my modem life, I've managed large downloads over friends and colleagues. Now I do manage them for they.
- Hartmut
Hartmut Birr wrote:
Alex Ionescu wrote:
Because it takes people on 56K modems 4 more hours to download the ISO.
It make no sense to discuss about the download time. The difference between both iso images is 1.3MB (10,762/12,078kB).
- Hartmut
You've chosen to compare the install images. The livecd difference is about 20MB.
Best regards, Alex Ionescu
Alex Ionescu wrote:
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.
Actually, an 8cm (single-sized) CD, which is fancy looking enough in my book, is about the size of a credit/debit card, and can hold 250MB. Isn't that enough to hold a livecd even bundled with other distro stuff?
See also: http://www.mufunyo.net/reactos/cdsizes.jpg
mf
From: Casper Hornstrup
The rsym section can be NOLOAD so there is no memory bloat.
It's already NOLOAD... What I do see as a potential problem is that the symbols are loaded into non-paged pool. This is because they're needed during a bug check, at which time we can't page them back in (or read them from the image file).
How about introducing a boot option /LOADSYMBOLS, defaulting to YES for DBG := 1 and NO for DBG := 0? That way, a user having a reproducible problem can be instructed to add that option so we can have a good stack trace. Maybe reporterror can load the symbols when needed? Just tossing around some ideas here.
Ge van Geldorp.
Ge van Geldorp wrote:
From: Casper Hornstrup
The rsym section can be NOLOAD so there is no memory bloat.
It's already NOLOAD... What I do see as a potential problem is that the symbols are loaded into non-paged pool.
I think that is not a problem. After starting up reactos, the symbols occupied 842,360 Byte of non paged pool on my test machine.
- Hartmut
Hartmut Birr wrote:
Ge van Geldorp wrote:
From: Casper Hornstrup
The rsym section can be NOLOAD so there is no memory bloat.
It's already NOLOAD... What I do see as a potential problem is that the symbols are loaded into non-paged pool.
I think that is not a problem. After starting up reactos, the symbols occupied 842,360 Byte of non paged pool on my test machine.
- Hartmut
I don't know how you're counting, because they occupy ~30MB on mine.
Best regards, Alex Ionescu
Ge van Geldorp wrote:
From: Casper Hornstrup
The rsym section can be NOLOAD so there is no memory bloat.
It's already NOLOAD... What I do see as a potential problem is that the symbols are loaded into non-paged pool. This is because they're needed during a bug check, at which time we can't page them back in (or read them from the image file).
How about introducing a boot option /LOADSYMBOLS, defaulting to YES for DBG := 1 and NO for DBG := 0? That way, a user having a reproducible problem can be instructed to add that option so we can have a good stack trace. Maybe reporterror can load the symbols when needed? Just tossing around some ideas here.
Ge van Geldorp.
Ge,
THANK YOU for coming up with something! I love this idea, because it gets rid of the memory problem, which is what mostly bothers me.
However, there is another one: gcc makes ntoskrnl 1.3MB with optimizations on and rsym "Stripping" the symbols. However, building with -s and then doing strip -x creates a 530KB file (this is what msvc would produce).
If we can somehow remove the 900KB "gcc bloat" and keep the symbols, I will be very happy (And the users too). The main reason I'm not so happy with the symbols is that we can't strip the files (afaik). The extra 800KB isn't symbol data...
Best regards, Alex Ionescu
From: Alex Ionescu
However, there is another one: gcc makes ntoskrnl 1.3MB with optimizations on and rsym "Stripping" the symbols. However, building with -s and then doing strip -x creates a 530KB file (this is what msvc would produce).
If we can somehow remove the 900KB "gcc bloat" and keep the symbols, I will be very happy (And the users too). The main reason I'm not so happy with the symbols is that we can't strip the files (afaik). The extra 800KB isn't symbol data...
Huh??? "objdump -h ntoskrnl.exe" gives:
Sections: Idx Name Size VMA LMA File off Algn 0 .text 000ae630 80001000 80001000 00001000 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 init 0000c128 800b0000 800b0000 000b0000 2**2 CONTENTS, ALLOC, LOAD, CODE 2 .data 000014c0 800bd000 800bd000 000bd000 2**4 CONTENTS, ALLOC, LOAD, DATA 3 .rdata 000178b0 800bf000 800bf000 000bf000 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .edata 0000b83d 800d7000 800d7000 000d7000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .idata 000007d4 800e3000 800e3000 000e3000 2**2 CONTENTS, ALLOC, LOAD, DATA 6 .rsrc 000015e8 800e4000 800e4000 000e4000 2**2 CONTENTS, ALLOC, LOAD, DATA 7 .bss 00021320 800e6000 800e6000 00000000 2**4 ALLOC 8 .reloc 00008cd0 80108000 80108000 000e6000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .rossym 000c7e88 80111000 80111000 000ef000 2**2 CONTENTS, READONLY, DEBUGGING, NEVER_LOAD, EXCLUDE
Please note the .rossym section, which contains the symbols. Section size 0xc7e88. Corresponds very nicely to the 800KB you mention.
Gé van Geldorp.
Ge van Geldorp wrote:
Huh??? "objdump -h ntoskrnl.exe" gives:
Sections: Idx Name Size VMA LMA File off Algn 0 .text 000ae630 80001000 80001000 00001000 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 init 0000c128 800b0000 800b0000 000b0000 2**2 CONTENTS, ALLOC, LOAD, CODE 2 .data 000014c0 800bd000 800bd000 000bd000 2**4 CONTENTS, ALLOC, LOAD, DATA 3 .rdata 000178b0 800bf000 800bf000 000bf000 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .edata 0000b83d 800d7000 800d7000 000d7000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .idata 000007d4 800e3000 800e3000 000e3000 2**2 CONTENTS, ALLOC, LOAD, DATA 6 .rsrc 000015e8 800e4000 800e4000 000e4000 2**2 CONTENTS, ALLOC, LOAD, DATA 7 .bss 00021320 800e6000 800e6000 00000000 2**4 ALLOC 8 .reloc 00008cd0 80108000 80108000 000e6000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .rossym 000c7e88 80111000 80111000 000ef000 2**2 CONTENTS, READONLY, DEBUGGING, NEVER_LOAD, EXCLUDE
Please note the .rossym section, which contains the symbols. Section size 0xc7e88. Corresponds very nicely to the 800KB you mention.
Gé van Geldorp.
Ok, well Casper kept insisting that rsym "strips" the symbols away. Doesn't look like it.
Thanks for clearing it up.
Best regards, Alex Ionescu
From: Alex Ionescu
Ok, well Casper kept insisting that rsym "strips" the symbols away. Doesn't look like it.
I believe Casper insisted that rsym strips the stabs symbols away... Which it does. It also removes COFF symbols. In return, it puts back the .rossym section which is about 1/5th the size of the .stabs symbols. The .rossym section contains the minimum info you need to do symbolic stack traces.
By the way, since the .rossym section is marked NEVER_LOAD, "strip" will happily remove it for you if really must.
Gé van Geldorp.
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Ge van Geldorp Sent: 29. maj 2005 21:55 To: 'ReactOS Development List' Subject: RE: [ros-dev] More RBuild issues...
From: Casper Hornstrup
The rsym section can be NOLOAD so there is no memory bloat.
It's already NOLOAD... What I do see as a potential problem is that the symbols are loaded into non-paged pool. This is because they're needed during a bug check, at which time we can't page them back in (or read them from the image file).
How about introducing a boot option /LOADSYMBOLS, defaulting to YES for DBG := 1 and NO for DBG := 0? That way, a user having a reproducible problem can be instructed to add that option so we can have a good stack trace. Maybe reporterror can load the symbols when needed? Just tossing around some ideas here.
Ge van Geldorp.
I am planning on making reporterror translating the addresses to symbols on the next boot after a crash in kernel-mode. This mean the symbols only need to be in memory during the period reporterror is translating a stack trace and only symbols for modules which are listed in the stack trace are needed to be loaded.
Symbols in BSOD screens are nice and all, but if you have network capability, reporterror would be much easier to use since you don't need to write down the stack trace on paper or grab a camera to report the information to a developer.
Casper
Casper Hornstrup wrote:
Symbols in BSOD screens are nice and all, but if you have network capability, reporterror would be much easier to use since you don't need to write down the stack trace on paper or grab a camera to report the information to a developer.
Coudn't they written to hd ? On reboot reporterror would ask if he may send it.
Maarten Bosma
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Maarten Bosma Sent: 30. maj 2005 18:38 To: ReactOS Development List Subject: Re: [ros-dev] More RBuild issues...
Casper Hornstrup wrote:
Symbols in BSOD screens are nice and all, but if you have network capability, reporterror would be much easier to use since you don't need to write down the stack trace on paper or grab a camera to report the information to a developer.
Coudn't they written to hd ? On reboot reporterror would ask if he may send it.
Exactly.
Casper
From: Ge van Geldorp
How about introducing a boot option /LOADSYMBOLS, defaulting to YES for DBG := 1 and NO for DBG := 0? That way, a user having a reproducible problem can be instructed to add that option so we can have a good stack trace.
Since noone objected to this idea, I've implemented it now (r15814).
Ge van Geldorp.
Alex Ionescu wrote:
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.
Unless, the developer doesn't want junk screaming at him/her, and only is interested in one area.
8^O OMG! What is all this stuff! James
Hi,
at the current state of reactos, it is more important to get the BSOD back. Someone ;-) has rewrote the debug system and since this time the BSOD isn't shown anymore.
- Hartmut
Alex Ionescu wrote:
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.
Ge van Geldorp.
Best regards, Alex Ionescu _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Hartmut Birr wrote:
Hi,
at the current state of reactos, it is more important to get the BSOD back. Someone ;-) has rewrote the debug system and since this time the BSOD isn't shown anymore.
- Hartmut
Hartmut,
What's up with the BSOD? It works for me... can you describe your issue please?
Best regards, Alex Ionescu
-
Alex Ionescu -
Casper Hornstrup -
Ge van Geldorp -
Hartmut Birr -
James Tabor -
Maarten Bosma -
mf -
Royce Mitchell III -
Thomas Weidenmueller