gnupic: Thread: Re: Segmentation fault ... other locations of problem and different types of fixes

This may or may not help.  There were 2 additional locations.  However each 
required a different type of fix to solve it.  Here they are
(btw, I do this at night ... so I don't get your mails 'til the next day)
Not to lecture (please do not take offense) ... from my days of teaching 
ANSI/ISO C for embedded systems ... variables whether initaialized or not can 
be used as indices for arrays.  C does not check bounds on array access. 
(Unlike Ada).


Example of problem #2
//BOOL get_hexbyte(BYTE *val)
BOOL get_hexbyte( BYTE *val, int *prxout)
{
    BYTE b;
    BOOL ok=0;

    *val = 0;
//    while (isxdigit(rxbuff[rxout]) && get_byte(&b))    //Segmentation Fault
//    while (isxdigit(rxbuff[*prxout]) && get_byte(&b))   //no help
    //Fixed with pointer arithmatic
    while ( isxdigit( *((BYTE *)(rxbuff) + *prxout)) && get_byte(&b))
    {
        ok = 1;
        *val <<= 4;
        if (b <= '9')
            *val += b - '0';
        else
            *val += (b-'A'+10) & 0xf;
    }
    return(ok);
}

Example of problem #3
//BYTE getch_slip(void)
BYTE getch_slip( int *prxout)
{
    BYTE b=0;

    slipend = rxout>=rxcount;
    if (!slipend)
    {
//        b = rxbuff[rxout++];		          //Segmentation Fault
        b = *(((BYTE *)rxbuff) + *prxout++);  //Fixed with pointer arithmatic
        *prxout++;
        check_byte(b);
    }
    return(b);
}


Hopefully this additional information helps
Thanks
Bob



On Wednesday 29 May 2002 09:30, Scott Dattalo wrote:
> On Tue, 28 May 2002, Robert Warner wrote:
> > Ok,  after several compile/edit sequences I've come up with the
> > following. It appears an array indexed with a variable causes a problem.
>
> And this is undoubtedly a bug in SDCC. I'll look into this right now...
>
> Thanks for the report,
> Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

On Wed, 29 May 2002, Robert Warner wrote:

> This may or may not help.  There were 2 additional locations.  However each 
> required a different type of fix to solve it.  Here they are

Yes, I have verified this. It's easy to stop the core dump by commenting
out the offending code. However, the generated assembly is still wrong. In
short, using variables to index into arrays is broken. Although I did fix
the simple case:

char buff[10];
char dummy, achar0;

....

;#CSRC	pointer1.c 90
;  dummy = buff[achar0];
	MOVF	_achar0,W	;key=000,flow seq=002
	ADDWF	_buff,W	;key=001,flow seq=002
	MOVWF	r0x2E	;key=002,flow seq=002
	MOVF	r0x2E,W	;key=003,flow seq=002
	MOVWF	FSR	;key=004,flow seq=002
	MOVF	INDF,W	;key=005,flow seq=002
	MOVWF	_dummy	;key=006,flow seq=002

The r0x2E business is overhead that I'll trim soon enough....


My next priority will be pointers. 

Scott

On Wed, 29 May 2002, Scott Dattalo wrote:

> On Wed, 29 May 2002, Robert Warner wrote:
> 
> > This may or may not help.  There were 2 additional locations.  However each 
> > required a different type of fix to solve it.  Here they are
> 
> Yes, I have verified this. It's easy to stop the core dump by commenting
> out the offending code. However, the generated assembly is still wrong. In

I meant, comment out the offending code in SDCC and not your source. (I 
reckon though, one way to reduce your code size is by deleting it :)

A few weeks ago, when I said that SDCC was usable by "the adeventerous",
if they didn't miond working around odd bugs ... below is exactly what
I meant.

These  types of bugs aren't acceptable for a production compiler used
by beginning programmers, but its very typical of new system bringup. 

(Its even more fun when your cpu chip is brand new too, and hasn't been
debugged yet either).

--linas

On Wed, May 29, 2002 at 05:54:58PM -0400, Robert Warner was heard to remark:
> This may or may not help.  There were 2 additional locations.  However each 
> required a different type of fix to solve it.  Here they are
> (btw, I do this at night ... so I don't get your mails 'til the next day)
> Not to lecture (please do not take offense) ... from my days of teaching 
> ANSI/ISO C for embedded systems ... variables whether initaialized or not can 
> be used as indices for arrays.  C does not check bounds on array access. 
> (Unlike Ada).
> 
> 
> Example of problem #2
> //BOOL get_hexbyte(BYTE *val)
> BOOL get_hexbyte( BYTE *val, int *prxout)
> {
>     BYTE b;
>     BOOL ok=0;
> 
>     *val = 0;
> //    while (isxdigit(rxbuff[rxout]) && get_byte(&b))    //Segmentation Fault
> //    while (isxdigit(rxbuff[*prxout]) && get_byte(&b))   //no help
>     //Fixed with pointer arithmatic
>     while ( isxdigit( *((BYTE *)(rxbuff) + *prxout)) && get_byte(&b))
>     {
>         ok = 1;
>         *val <<= 4;
>         if (b <= '9')
>             *val += b - '0';
>         else
>             *val += (b-'A'+10) & 0xf;
>     }
>     return(ok);
> }
> 
> Example of problem #3
> //BYTE getch_slip(void)
> BYTE getch_slip( int *prxout)
> {
>     BYTE b=0;
> 
>     slipend = rxout>=rxcount;
>     if (!slipend)
>     {
> //        b = rxbuff[rxout++];		          //Segmentation Fault
>         b = *(((BYTE *)rxbuff) + *prxout++);  //Fixed with pointer arithmatic
>         *prxout++;
>         check_byte(b);
>     }
>     return(b);
> }
> 
> 
> Hopefully this additional information helps
> Thanks
> Bob
> 
> 
> 
> On Wednesday 29 May 2002 09:30, Scott Dattalo wrote:
> > On Tue, 28 May 2002, Robert Warner wrote:
> > > Ok,  after several compile/edit sequences I've come up with the
> > > following. It appears an array indexed with a variable causes a problem.
> >
> > And this is undoubtedly a bug in SDCC. I'll look into this right now...
> >
> > Thanks for the report,
> > Scott
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ####@####.####
> > For additional commands, e-mail: ####@####.####
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) ####@####.####
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933

On Thu, 30 May 2002, Linas Vepstas wrote:

> 
> A few weeks ago, when I said that SDCC was usable by "the adeventerous",
> if they didn't miond working around odd bugs ... below is exactly what
> I meant.

And I concur. At this stage of the game the PIC port is still not suitable 
for commercial projects and marginally suitable for hobbyists. But as bug 
reports like these roll and are fixed, it'll soon be ready for both.

Many of the pointer issues related to what Bob has reported have already 
been fixed (but are not in CVS yet). 

If anyone else cares to be "adventurous", I'll glady assist in negotiating 
around the obstacles.

Scott

> On Thu, 30 May 2002, Linas Vepstas wrote:
> > A few weeks ago, when I said that SDCC was usable by "the adeventerous",
> > if they didn't miond working around odd bugs ... below is exactly what
> > I meant.
>
> If anyone else cares to be "adventurous", I'll glady assist in negotiating
> around the obstacles.
>
I've always enjoyed bring up BSPs on new micros, or porting old to new code 
on micros.  Compiler issues are just part of the fun.  I'll be continuing  on 
with this effort (cause I can't afford the other higher priced PIC compilers) 
for 'at home' projects.  Soo ... unto more code-spelunking ... ;)

Bob