From: Mike L. <mi...@ho...> - 2002-06-28 15:27:57
|
packet currently appears in two places, user mode libraries and kernel mode networking drivers. Can someone tell me which is the correct place for it. Mike Lerwill |
From: Mike L. <mi...@ho...> - 2002-06-28 16:23:23
|
Apologies for replying to my own question, looking further I see that they are two separate items. I had assumed that it was an error introduced by the recent moving things around. However the top level makefile seems to be confused with them having the same name, I am referring to the following warnings makefile:671: warning: overriding commands for target `packet' makefile:526: warning: ignoring old commands for target `packet' makefile:674: warning: overriding commands for target `packet_implib' makefile:529: warning: ignoring old commands for target `packet_implib' makefile:677: warning: overriding commands for target `packet_clean' makefile:532: warning: ignoring old commands for target `packet_clean' makefile:680: warning: overriding commands for target `packet_install' makefile:535: warning: ignoring old commands for target `packet_install' makefile:683: warning: overriding commands for target `packet_dist' makefile:538: warning: ignoring old commands for target `packet_dist' regards Mike Lerwill > -----Original Message----- > From: rea...@li... > [mailto:rea...@li...]On Behalf Of Mike > Lerwill > Sent: 28 June 2002 16:28 > To: Ros-Kernel > Subject: [ros-kernel] packet in makefile > > > packet currently appears in two places, user mode libraries and > kernel mode > networking drivers. > > Can someone tell me which is the correct place for it. > > Mike Lerwill > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Caffeinated soap. No kidding. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > |
From: David W. <we...@cw...> - 2002-06-28 18:50:50
|
On Fri, Jun 28, 2002 at 05:23:18PM +0100, Mike Lerwill wrote: > > packet currently appears in two places, user mode libraries and > > kernel mode > > networking drivers. > > > > Can someone tell me which is the correct place for it. > > I think that both locations are correct. The targets in the toplevel makefile need to have different names however. |
From: Casper H. <ch...@us...> - 2002-06-29 00:18:24
Attachments:
stabs.tar.gz
|
While trying to make the loader understand .stabs sections, I face a problem with non-standard PE image sections. The problem is that when the .stabs image section is read from, an access violation occur. The image section has PAGE_READONLY (0x2) as protection so what else can give this access violation? Casper |
From: David W. <we...@cw...> - 2002-06-29 10:28:05
|
On Sat, Jun 29, 2002 at 02:06:01AM +0200, Casper Hornstrup wrote: > While trying to make the loader understand .stabs sections, I face a > problem with non-standard PE image sections. > > The problem is that when the .stabs image section is read from, an > access violation occur. The image section has PAGE_READONLY (0x2) as > protection so what else can give this access violation? > The loader doesn't load NOLOAD sections so your code wouldn't be able to find stabs/stabstr sections in the mapping of images, it will need to look in the original executable. I think it would be better to seperate the debugging sections of the unstripped executables into another file as NT does to save space. Additionally wouldn't it be easier to do the interpretation of the debugging information in the debugger - either pice/kdb for in-kernel debugging or gdb for debugging over a serial line. |
From: Robert D. <od...@pn...> - 2002-06-29 18:14:19
|
This bitmap file font.bmp is seriously garbled in CVS. If anybody has a good version would they please update CVS or post it to the list. Thanks, Robert. |
From: Brian P. <br...@sg...> - 2002-07-02 04:20:09
|
Yes, it seems that all the files in that directory were committed as text files. I've recommitted the necessary files as binary. Brian > -----Original Message----- > From: rea...@li... [mailto:reactos-kernel- > ad...@li...] On Behalf Of Robert Dickenson > Sent: Saturday, June 29, 2002 12:26 PM > To: rea...@li... > Subject: [ros-kernel] garbled bitmap file in rosapps/taskmgr > > This bitmap file font.bmp is seriously garbled in CVS. > > If anybody has a good version would they please > update CVS or post it to the list. > > Thanks, Robert. > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > No, I will not fix your computer. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
From: Casper H. <ch...@us...> - 2002-06-30 00:35:06
|
l=F8r, 2002-06-29 kl. 13:26 skrev David Welch: > On Sat, Jun 29, 2002 at 02:06:01AM +0200, Casper Hornstrup wrote: > > While trying to make the loader understand .stabs sections, I face a > > problem with non-standard PE image sections. > >=20 > > The problem is that when the .stabs image section is read from, an > > access violation occur. The image section has PAGE_READONLY (0x2) as > > protection so what else can give this access violation? > >=20 > The loader doesn't load NOLOAD sections so your code wouldn't be able to > find stabs/stabstr sections in the mapping of images, it will need to loo= k=20 > in the original executable. I think it would be better to seperate the > debugging sections of the unstripped executables into another file as NT=20 > does to save space. Additionally wouldn't it be easier to do the=20 > interpretation of the debugging information in the debugger - either=20 > pice/kdb for in-kernel debugging or gdb for debugging over a serial line. I want to keep it simple. Just enough to display source filename, linenumber, and function name of the point of a crash and the stack frames when DBG =3D 1. This will make it a lot easier for users to report crashes and for developers to act on them. I don't like having one extra file per image just for this. GDB understands stabs sections perfectly, but for "normal" users and some betatesters, using a debugger is too complicated and currently requires two machines. I tried using ZwOpenFile() (with SHARE_READ_ACCESS) to open the image, but all I got was STATUS_UNSUCCESSFUL. The image is already mapped at this point, but should I not be able to do this (this was with smss.exe)? Casper |
From: David W. <we...@cw...> - 2002-06-30 09:09:04
|
On Sat, Jun 29, 2002 at 01:55:16PM +0200, Casper Hornstrup wrote: > I don't like having one extra file per image just for this. > For ntoskrnl, the extra debugging information is ~1MB so I think it is unavoidable. > GDB understands stabs sections perfectly, but for "normal" users and > some betatesters, using a debugger is too complicated and currently > requires two machines. > I agree that we should make it easier for users to report problems. A different approach would to be to add a core dump facility; the basic version would dump only the trap frame and a few other bits of information. It could then be decoded offline with addr2line. > I tried using ZwOpenFile() (with SHARE_READ_ACCESS) to open the image, > but all I got was STATUS_UNSUCCESSFUL. The image is already mapped at > this point, but should I not be able to do this (this was with > smss.exe)? > I don't know why that would fail. Vfatfs doesn't even seem to check the sharing mode. |