28 May
2005
28 May
'05
11:39 p.m.
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.
29 May
29 May
7:55 a.m.
-----Original Message-----
From: ros-dev-bounces(a)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...
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.
I'll look at this.
2) 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
9:01 a.m.
-----Original Message-----
From: ros-dev-bounces(a)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...
2) 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
2:52 p.m.
Casper Hornstrup wrote:
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.
-----Original Message-----
From: ros-dev-bounces(a)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...
2) 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
Best regards,
Alex Ionescu
3:07 p.m.
From: Alex Ionescu
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.
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.
3:19 p.m.
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
4:47 p.m.
Thomas Weidenmueller wrote:
Ge van Geldorp wrote:
Then I can only hope I will be granted the same patience with the new
headers and tree structure.
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
Best regards,
Alex Ionescu
4:46 p.m.
Ge van Geldorp wrote:
He is, and I haven't denied this.
From: Alex
Ionescu
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.
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.
Best regards,
Alex Ionescu
3:52 p.m.
-----Original Message-----
From: ros-dev-bounces(a)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:
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.
>-----Original Message-----
>From: ros-dev-bounces(a)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. If anyone has the right to be annoyed, it's the
developers, who since
yesterday, have been:
1) 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.
2) Unable to boot ROS
You haven't even posted your configuration yet. Do you think I'm psychic?
3) 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
4:52 p.m.
Casper Hornstrup wrote:
I'm sorry...in any case...both me and Filip can boot now..thank you.
Good point, but even 3.4.3 is broken....well, not after my "annoying"
fixes...
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
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 :)
2) Unable to
boot ROS
You haven't even posted your configuration yet. Do you think I'm psychic?
3) 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
5:43 p.m.
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
6:01 p.m.
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.
6:45 p.m.
Ge van Geldorp wrote:
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.
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.
Best regards,
Alex Ionescu
7:21 p.m.
-----Original Message-----
From: ros-dev-bounces(a)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:
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
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.
7:41 p.m.
Casper Hornstrup wrote:
Us, before release. Just like Microsoft tests the "free" build after
they are done working with the "Checked one"
-----Original Message-----
From: ros-dev-bounces(a)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:
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?
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.
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
8:04 p.m.
New subject: Symbol handling
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? 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
30 May
30 May
1:27 p.m.
New subject: XML-Build and rosapps
I just want to point out that thunk/posix, trunk/os2, trunk/vms and
rosapps are still using the old build system.
Maarten Bosma
8:32 p.m.
Hartmut Birr wrote:
Alex Ionescu wrote:
FWIW, 1.3MB = appx 7 minutes download time on my 26k connection.
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).
9:12 p.m.
Royce Mitchell III wrote:
Hartmut Birr wrote:
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
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.
30 May
30 May
2:43 a.m.
Hartmut Birr wrote:
Alex Ionescu wrote:
You've chosen to compare the install images. The livecd difference is
about 20MB.
Best regards,
Alex Ionescu
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
____
11:54 a.m.
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
29 May
29 May
7:55 p.m.
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.
8:05 p.m.
Ge van Geldorp wrote:
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
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.
30 May
30 May
2:43 a.m.
Hartmut Birr wrote:
Ge van Geldorp wrote:
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
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.
2:46 a.m.
Ge van Geldorp wrote:
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: 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.
8:23 a.m.
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.
2:43 p.m.
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
3:16 p.m.
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.
4:19 p.m.
-----Original Message-----
From: ros-dev-bounces(a)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...
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
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.
4:37 p.m.
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
5:13 p.m.
-----Original Message-----
From: ros-dev-bounces(a)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:
Exactly.
Casper
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.
5 Jun
5 Jun
9:03 p.m.
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.
29 May
29 May
7:23 p.m.
Alex Ionescu wrote:
Ge van Geldorp wrote:
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
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.
7:52 p.m.
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:
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.
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.
Best regards,
Alex Ionescu
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
30 May
30 May
2:47 a.m.
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
7142
days inactive
7150
days old
37 comments
9 participants
participants (9)
-
Alex Ionescu -
Casper Hornstrup -
Ge van Geldorp -
Hartmut Birr -
James Tabor -
Maarten Bosma -
mf -
Royce Mitchell III -
Thomas Weidenmueller