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 |