Mail Archives: djgpp/1998/06/11/00:51:05
George Foot answered:
>I have wrote:
(hope that is clear)
>: I am adding some debuging capabilities to my PPCol library but I don't
>: know how to force the output of the traceback, so the user can trace all
the
>: calls to functions and look where happened the problem.
>
>I think the problem is that the signal is raised by your call
>directly, and so __djgpp_exception_state_ptr is not set properly; this
>means that the register status, etc, is not available to the traceback
>printer in the normal way. I found this out a while ago. I only had
>the sources for version 2.02 on my hard drive, which seem to have this
>fixed (or fudged...); although the default handler doesn't get the
>information, my replacement handler (which generates core dumps
>containing the information) does work, because it uses the same system
>that the v2.02 library uses.
So, it is a DJGPP bug or not? If it is a bug I will leave the library as
it is now without the traceback output but at least it stops before
accesing the bad memory. And then when v2.02 gets out, it will start to work.
>You could do the fix in your code before raising the signal, I
>think... but that would be ugly. IIRC:
>
> jmp_buf fake_exception_state;
> if (setjmp (fake_exception_state)) { /* shouldn't happen */
> fprintf (stderr, "Argh!\n");
> exit (-1);
> }
> __djgpp_exception_state_ptr = &fake_exception_state;
> raise(SIG...);
>
>I can't test this now, because I can't run djgpp on this computer. I
>don't think this is a nice way to solve the problem though.
I don't understand anything of that! What it does? Also I have never used
setjmp() and all that things... I am a medium newbie.
>The most robust way is probably to generate the traceback yourself.
>It's not too hard; you get the value of EBP. At that location in your
>stack segment (same as data segment) is the next value for EBP
>(32-bit), and at EBP+4 is the EIP to print. Keep going until *(int
>*)EBP is zero; don't print ((int *)EBP)[1] here.
Assembly: I don't know anything about that... or only a small bit...
>The best way to see this is to get the library source, and look in
>src/libc/go32/dpmiexcp.c at the function `show_call_frame'. It's
>slightly complicated because it reads its values from
>__djgpp_exception_state (which you can't do). You can use some short
>inline assembly to get the register contents you need (just EBP and
>perhaps EIP, really).
Too complex for my knowledge...
>In fact everything I've suggested here doesn't feel `nice' to me; I'm
>sorry if it's not very useful!
Ok, thankyou anyway. I would like to know if it is a V2.01 bug that will
be corrected for V2.02 or not.
>: Some bad DPMI servers don't detect some bad memory accesses... I don't
>: know what happens when you access the NULL space with this DPMI servers...
>: maybe in that situation they detect it, but someone know if this is 100%
>: effective? I don't have tried it under W95 yet... sorry... I don't have
much
>: time...
>
>Relying on the NULL page is probably not a good idea, for the reason
>you gave -- Win95 for instance doesn't detect the accesses.
Yes, under real DOS with CWSDPMI (I love that DPMI server, thank you
Charles) it detects the bad access everytime I have tested it. Under W95 I
don't have tested yet but I am pretty sure that it will don't (thank you
Bill :-))) )
Ok, thanks again George! Goodbye!
P.s: BTW: when will DJDEV V2.02 be released? Someone has any idea?
Ivan Baldo:
lubaldo AT adinet DOT com DOT uy - http://members.xoom.com/baldo - ICQ 10215364
Phone: (598) (2) 613 3223.
Caldas 1781, Malvin, Montevideo, Uruguay, South America.
(If you have problems with the previous addresses, try this ones:
ibaldo AT usa DOT net, http://baldo.home.ml.org).
- Raw text -