Date: Wed, 11 Jan 1995 16:38:21 +0900 From: Stephen Turnbull To: bdavidson AT ra DOT isisnet DOT com Cc: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: Should "topline" report MORE memory than GO32 does? [was: Ramdrive] to you (although was _pretty_ sure). Now go32 reports 1400Kb, and topline under info reports 1768Kb!! (aside: surely KB not Kb; I always Any gurus out there know what's going on here? Looks like something is confused about how much memory there is! Is it GO32 or Info or what? thought KB meant KiloBytes and Kb meant Kilobits!). Pedant. The rest of this is rather FAQ-y; techies can flush the rest of this message. More bad news! Since I have trouble reading the docs [ ;( ] I don't know how symify works (or what it is); I presume -g means "compile with debug info" (-g == debug; Of course!). To get this do I have to get all the sources, re-apply the maint releases, and compile? No. Just get the sources for texinfo. I guess to be safe you could reapply the maint releases but I don't recall seeing any texinfo patches in them. Symify [usage: symify ] generates symbolic (ie, function names) addresses from the numerical addresses in the stack trace. It reads the stack trace right off the screen; so anytime a "-g" compiled executable GPFs, you just run symify immediately and it tells you where the GPF was, and what sequence of function calls got you there. QUERY: How do I read the top line under GO32=topline? What is that hex From left to right: - if paging, will be present, else absent - malloc, paging, whatever This may not be entirely accurate, it's from memory. number in the middle, and why does it write over everything while everthing writes over the stuff I want to see? How do I know when go32 is paging, etc? It's pretty simple-minded, just writes to the top line of the screen at present. Works well for screen oriented output, tends to not be there when you want it for line-oriented output (like stdout or stderr). Also, I don't see any docs for symify, although symify is in my bin directory. Is it buried in there somewhere? I have spent some time squinting at the .inf files to glean what I can, but haven't seen symify in there. Nope, docs are the least satisfactory aspect of DJGPP. You can get Eli Zaretskii's FAQ (I think it's pretty reliable, but DJ hasn't made it official yet) at URL file://turnbull.sk.tsukuba.ac.jp/public-ftp/djgpp/list-archive/EZ-FAQ.beta if you're on the Web (in which case you might find http://turnbull.sk.tsukuba.ac.jp/#djgpp of use); or anonymous FTP to my host, directory pub/djgpp/list-archive. and protection faults. That is what I find weird. The same sequence of commands under the same environment produces different (or differently reported) exceptions at different points in the program. I would have thought that I would see the problem at *exactly* the same place after *exactly* the same commands (and it would raise the same error message). It is probably not worth your time to try to gt symify to work on info stack traces then. Sounds like an OS problem. Thanx, and BTW, I know you must have a REAL job, not just answering my questions, and I sure appreciate the trouble you have taken so far to help me out! Have a good one yourself, and if you are ever in Halifax, Nova Scotia, look me up and we will share a virtual ale! Well I get to Toronto occasionally and have brother in Boston, mother in Woodstock NY. Maybe.... But I hope it's not virtual! As you can see from the host above, I have been a little bit involved in docs for DJGPP. Beats doing real work. --Steve