From:	sandmann AT clio DOT rice DOT edu (Charles W. Sandmann)
Subject:	Re: -pg profiling bug
To:	S_Eckart AT lis DOT e-technik DOT tu-muenchen DOT de (Stefan Eckart)
Date:	Sun, 16 Jan 1994 14:25:49 -0600 (CST)
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu (DJGPP Mailing List)

> The following program generates a segmentation violation when run
> after being compiled with the -pg option:
> 
> Segmentation violation in pointer 0x1b036702 at d8:1248
> eax=2b036702 ebx=00000006 ecx=0000007d edx=e002591f esi=0002592b edi=0008b410
> ebp=7ffffe10 esp=7ffffdaa cs=d8 ds=38 es=48 fs=48 gs=38 ss=48 cr2=00006702
> Call frame traceback EIPs:
>   0x00001248   __exit+162
>   0x00001a26   _fread+66
>   0x000014d5   _main+97
> 
> Looking into the code with edebug32 shows the opcode at 0x1248 to be the
> incw (%eax) in mcount_isr in crt0.s. 

With this excellently detailed report, I can tell you what the bug is and
hopefully how to fix it (sorry, I'm too busy to try it myself).  Looking at
the traceback above, ds=38, which is the core selector.  (The code was 
obviously in the middle of a transfer from the transfer buffer).  If you look
in CRT0.S, the interrupt routine incorrectly assumes that DS will be 
set to what it expects it to be.

The fix is to store DS in the code segment in the init routine, push DS, store 
DS from the CS: offset in the interrupt routine, do the operations, then pop the
old DS on exit.  The garbage pointer is caused by adding mcount_histogram to EAX
- which the offset is recovered from the wrong segment.  Since
things like our wrapper routines could be copied to malloced space, this
routine should also be modified to check for writing in the limits of what
it allocated.  (But in this case, you might still fail since the limit
offset to gather might also be garbage).  Fix the DS to be set properly
and I hope this will fix the profiling bug you have described.

- Raw text -