Compiling WP-34S

[jpcuzzourt]

I'm attempting to compile WP34S from sources.
I've checked source out using svn. Current revision is 3912.
I haven't modified the code.
I'm getting an error from keys.c about a misleading indent (line 2057)

I can see what it means about the misleading indent, but "fixing" that, either by unindenting line 2057 or bracketing 2056-67, of course does not resolve the fact that it is trying to return a value to main() - it only gets rid of the misleading indent warning.
I'm trying to find an unmatched brace or something to account for it, but I'm not familiar with this code, and I'm struggling. I'm hoping one of the devs might be willing to have a look and confirm the intention on line 2056-57 and help me find where this is going wrong?
Please?
I'm trying to get to the point that I can compile it all, including the QT gui for linux.

Code:


arm-none-eabi-gcc -mthumb -mcpu=arm7tdmi -Os -fira-region=one -Wall -Werror -g -fno-common -fno-exceptions  -DREALBUILD=1 -Dat91sam7l128=1 -Iatmel -DNO_BACKUP_INIT=1 -DNO_RAM_COPY=1 -IdecNumber -o realbuild/calc -nostartfiles  -T wp34s.lds -Wl,--gc-sections,-Map=realbuild/mapfile.txt \
    atmel/board_cstartup.S asone.c -nostdlib -lgcc -LLinux64_realbuild/obj -lconsts -fwhole-program -ldecNum34s # -save-temps
main.c: In function 'main':
<built-in>: error: function declared 'noreturn' has a 'return' statement [-Werror]
In file included from asone.c:49:0:
keys.c: In function 'process_multi':
keys.c:2055:3: error: this 'else' clause does not guard... [-Werror=misleading-indentation]
   else
   ^~~~
keys.c:2057:4: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else'
    return STATE_UNFINISHED;
    ^~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:348: realbuild/calc.bin] Error 1
jpcuzzourt@mx:~/wp34s/wp34s-code
$

Here is the code snippet:

Code:


$ cat -n keys.c|sed -n '2031,2063p'
  2031        switch (c) {
  2032        case K20:    // Enter - exit multi mode, maybe return a result
  2033            if (shift != SHIFT_N)
  2034                    break;
  2035            reset_multi();
  2036            if (State2.numdigit == 0)
  2037                return STATE_UNFINISHED;
  2038            else if (State2.numdigit == 1)
  2039                State2.digval2 = 0;
  2040            goto fin;
  2041    
  2042        case K24:    // Clx - backspace, clear alpha
  2043            if (shift != SHIFT_H) {
  2044                if (State2.numdigit == 0)
  2045                    reset_multi();
  2046                else
  2047                    State2.numdigit--;
  2048                return STATE_UNFINISHED;
  2049            }
  2050            break;
  2051    
  2052        case K60:    // EXIT/ON maybe case switch, otherwise exit alpha
  2053            if (shift == SHIFT_F)
  2054                State2.alphashift = 1 - State2.alphashift;
  2055            else
  2056                reset_multi();
  2057                return STATE_UNFINISHED;
  2058            
  2059    
  2060        default:
  2061            break;
  2062            }
  2063

[Paul Dale]

Unindent the return statement to match the indentation of the preceding if and else.
The other error will be more difficult, the main() function does not return for native builds.

It looks like you are trying to build calculator firmware. We had all sorts of problems with arm tool chains introducing bugs. In the end we had to go with a specific version which is now very old. It wasn't advanced enough to produce the diagnostic messages you are seeing.

As for a Qt Linux version, I've never built such. I still use the text console mode when a bug comes up, you really don't want to go there -- I suspect I'm the only person who has ever used it


Pauli

[jpcuzzourt]

(11-24-2019 09:52 AM)Paul Dale Wrote:  Unindent the return statement to match the indentation of the preceding if and else.
The other error will be more difficult, the main() function does not return for native builds.

It looks like you are trying to build calculator firmware. We had all sorts of problems with arm tool chains introducing bugs. In the end we had to go with a specific version which is now very old. It wasn't advanced enough to produce the diagnostic messages you are seeing.

As for a Qt Linux version, I've never built such. I still use the text console mode when a bug comes up, you really don't want to go there -- I suspect I'm the only person who has ever used it


Pauli

Thanks for the response. Yes, without having found any build instructions, I just jumped in to see what I could manage and learn. I started with the linux-build-arm script and figured once I got all the necessary build chain established for that, I could try looking at the QT stuff. And yes, I'm using all the current Debian stable build tools. (gcc version 8.3 and arm-none-eabi-gcc version 7.3.1)
I had managed building the QT linux version of newRPL, and so I have a lot of that build environment set up and working.
Again, thanks for letting me know the intention of the else clause. Maybe I'll be able to sort out where it's getting mixed up! (EDIT: turning off -Werror patches this issue - the compiler can't prove whether the return() is going to execute or not, and so it flags the warning. -Werror treats the warning as an error. There are smarter ways to do this, but not for me, not right now.)
-JP

EDIT: Oh, one more thing - you may or may not be interested in the warnings that my tools are generating for pretty.c in compile_cats.c. I haven't looked into these at all yet, but they seem to be indicating some potential buffer overruns.

Code:

In file included from compile_cats.c:1287:
pretty.c: In function ‘dump_opcodes’:
pretty.c:608:28: warning: ‘%s’ directive writing up to 499 bytes into a region of size 493 [-Wformat-overflow=]
      sprintf(temp, "[cmplx]%s", cmdpretty);
                            ^~   ~~~~~~~~~
pretty.c:608:6: note: ‘sprintf’ output between 8 and 507 bytes into a destination of size 500
      sprintf(temp, "[cmplx]%s", cmdpretty);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:596:28: warning: ‘%s’ directive writing up to 499 bytes into a region of size 493 [-Wformat-overflow=]
      sprintf(temp, "[cmplx]%s", cmdpretty);
                            ^~   ~~~~~~~~~
pretty.c:596:6: note: ‘sprintf’ output between 8 and 507 bytes into a destination of size 500
      sprintf(temp, "[cmplx]%s", cmdpretty);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:422:20: warning: ‘%s’ directive writing up to 499 bytes into a region of size 49 [-Wformat-overflow=]
     sprintf(buf, "'%s'", strlen(cmdpretty) == 3 ? cmdpretty : cmdalias);
                    ^~
pretty.c:422:5: note: ‘sprintf’ output between 3 and 502 bytes into a destination of size 50
     sprintf(buf, "'%s'", strlen(cmdpretty) == 3 ? cmdpretty : cmdalias);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:424:28: warning: ‘%s’ directive writing up to 499 bytes into a region of size 492 [-Wformat-overflow=]
     sprintf(temp, "[alpha] %s", cmdpretty);
                            ^~   ~~~~~~~~~
pretty.c:424:5: note: ‘sprintf’ output between 9 and 508 bytes into a destination of size 500
     sprintf(temp, "[alpha] %s", cmdpretty);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:507:19: warning: ‘%s’ directive writing up to 499 bytes into a region of size 50 [-Wformat-overflow=]
     sprintf(buf, "%s Z", cmdpretty);
                   ^~     ~~~~~~~~~
pretty.c:507:5: note: ‘sprintf’ output between 3 and 502 bytes into a destination of size 50
     sprintf(buf, "%s Z", cmdpretty);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:501:19: warning: ‘%s’ directive writing up to 499 bytes into a region of size 50 [-Wformat-overflow=]
     sprintf(buf, "%s Y", cmdpretty);
                   ^~     ~~~~~~~~~
pretty.c:501:5: note: ‘sprintf’ output between 3 and 502 bytes into a destination of size 50
     sprintf(buf, "%s Y", cmdpretty);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:490:23: warning: ‘%c’ directive writing 1 byte into a region of size between 0 and 499 [-Wformat-overflow=]
     sprintf(temp, "%s %c%c%c%c", cmdpretty,
                       ^~
pretty.c:490:5: note: ‘sprintf’ output between 6 and 505 bytes into a destination of size 500
     sprintf(temp, "%s %c%c%c%c", cmdpretty,
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       REGNAMES[c & 3], REGNAMES[(c >> 2) & 3],
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       REGNAMES[(c >> 4) & 3], REGNAMES[(c >> 6) & 3]);
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:455:30: warning: ‘%s’ directive writing up to 499 bytes into a region of size 491 [-Wformat-overflow=]
      sprintf(temp, "[cmplx]# %s", cmdpretty);
                              ^~   ~~~~~~~~~
pretty.c:455:6: note: ‘sprintf’ output between 10 and 509 bytes into a destination of size 500
      sprintf(temp, "[cmplx]# %s", cmdpretty);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:455:30: warning: ‘%s’ directive writing up to 499 bytes into a region of size 491 [-Wformat-overflow=]
      sprintf(temp, "[cmplx]# %s", cmdpretty);
                              ^~   ~~~~~~~~~
pretty.c:455:6: note: ‘sprintf’ output between 10 and 509 bytes into a destination of size 500
      sprintf(temp, "[cmplx]# %s", cmdpretty);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:461:23: warning: ‘%s’ directive writing up to 499 bytes into a region of size 498 [-Wformat-overflow=]
      sprintf(temp, "# %s", cmdpretty);
                       ^~   ~~~~~~~~~
pretty.c:461:6: note: ‘sprintf’ output between 3 and 502 bytes into a destination of size 500
      sprintf(temp, "# %s", cmdpretty);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Paul Dale]

The pretty.c ones are almost certainly furfies. It is printing instructions there and none are ever even remotely close to the buffer length -- they fit on the screen which limits the output to just over 20 characters (from memory, so probably wrong). I think you need to disable -Werror and ignore them. Or get an older compiler. There isn't a lot of compile time optimisation used for the firmware -- size is the most important factor rather than speed.

Dig into the Makefile, make sure your machine is being properly detected and modify the environment variable settings as required. You're treading into an area I've never used. Pascal or Marcus might be able to assist maybe?


Pauli

(11-24-2019 10:31 AM)jpcuzzourt Wrote:  

(11-24-2019 09:52 AM)Paul Dale Wrote:  Unindent the return statement to match the indentation of the preceding if and else.
The other error will be more difficult, the main() function does not return for native builds.

It looks like you are trying to build calculator firmware. We had all sorts of problems with arm tool chains introducing bugs. In the end we had to go with a specific version which is now very old. It wasn't advanced enough to produce the diagnostic messages you are seeing.

As for a Qt Linux version, I've never built such. I still use the text console mode when a bug comes up, you really don't want to go there -- I suspect I'm the only person who has ever used it


Pauli

Thanks for the response. Yes, without having found any build instructions, I just jumped in to see what I could manage and learn. I started with the linux-build-arm script and figured once I got all the necessary build chain established for that, I could try looking at the QT stuff. And yes, I'm using all the current Debian stable build tools. (gcc version 8.3 and arm-none-eabi-gcc version 7.3.1)
I had managed building the QT linux version of newRPL, and so I have a lot of that build environment set up and working.
Again, thanks for letting me know the intention of the else clause. Maybe I'll be able to sort out where it's getting mixed up! (EDIT: turning off -Werror patches this issue - the compiler can't prove whether the return() is going to execute or not, and so it flags the warning. -Werror treats the warning as an error. There are smarter ways to do this, but not for me, not right now.)
-JP

EDIT: Oh, one more thing - you may or may not be interested in the warnings that my tools are generating for pretty.c in compile_cats.c. I haven't looked into these at all yet, but they seem to be indicating some potential buffer overruns.

Code:

In file included from compile_cats.c:1287:
pretty.c: In function ‘dump_opcodes’:
pretty.c:608:28: warning: ‘%s’ directive writing up to 499 bytes into a region of size 493 [-Wformat-overflow=]
      sprintf(temp, "[cmplx]%s", cmdpretty);
                            ^~   ~~~~~~~~~
pretty.c:608:6: note: ‘sprintf’ output between 8 and 507 bytes into a destination of size 500
      sprintf(temp, "[cmplx]%s", cmdpretty);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:596:28: warning: ‘%s’ directive writing up to 499 bytes into a region of size 493 [-Wformat-overflow=]
      sprintf(temp, "[cmplx]%s", cmdpretty);
                            ^~   ~~~~~~~~~
pretty.c:596:6: note: ‘sprintf’ output between 8 and 507 bytes into a destination of size 500
      sprintf(temp, "[cmplx]%s", cmdpretty);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:422:20: warning: ‘%s’ directive writing up to 499 bytes into a region of size 49 [-Wformat-overflow=]
     sprintf(buf, "'%s'", strlen(cmdpretty) == 3 ? cmdpretty : cmdalias);
                    ^~
pretty.c:422:5: note: ‘sprintf’ output between 3 and 502 bytes into a destination of size 50
     sprintf(buf, "'%s'", strlen(cmdpretty) == 3 ? cmdpretty : cmdalias);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:424:28: warning: ‘%s’ directive writing up to 499 bytes into a region of size 492 [-Wformat-overflow=]
     sprintf(temp, "[alpha] %s", cmdpretty);
                            ^~   ~~~~~~~~~
pretty.c:424:5: note: ‘sprintf’ output between 9 and 508 bytes into a destination of size 500
     sprintf(temp, "[alpha] %s", cmdpretty);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:507:19: warning: ‘%s’ directive writing up to 499 bytes into a region of size 50 [-Wformat-overflow=]
     sprintf(buf, "%s Z", cmdpretty);
                   ^~     ~~~~~~~~~
pretty.c:507:5: note: ‘sprintf’ output between 3 and 502 bytes into a destination of size 50
     sprintf(buf, "%s Z", cmdpretty);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:501:19: warning: ‘%s’ directive writing up to 499 bytes into a region of size 50 [-Wformat-overflow=]
     sprintf(buf, "%s Y", cmdpretty);
                   ^~     ~~~~~~~~~
pretty.c:501:5: note: ‘sprintf’ output between 3 and 502 bytes into a destination of size 50
     sprintf(buf, "%s Y", cmdpretty);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:490:23: warning: ‘%c’ directive writing 1 byte into a region of size between 0 and 499 [-Wformat-overflow=]
     sprintf(temp, "%s %c%c%c%c", cmdpretty,
                       ^~
pretty.c:490:5: note: ‘sprintf’ output between 6 and 505 bytes into a destination of size 500
     sprintf(temp, "%s %c%c%c%c", cmdpretty,
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       REGNAMES[c & 3], REGNAMES[(c >> 2) & 3],
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       REGNAMES[(c >> 4) & 3], REGNAMES[(c >> 6) & 3]);
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:455:30: warning: ‘%s’ directive writing up to 499 bytes into a region of size 491 [-Wformat-overflow=]
      sprintf(temp, "[cmplx]# %s", cmdpretty);
                              ^~   ~~~~~~~~~
pretty.c:455:6: note: ‘sprintf’ output between 10 and 509 bytes into a destination of size 500
      sprintf(temp, "[cmplx]# %s", cmdpretty);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:455:30: warning: ‘%s’ directive writing up to 499 bytes into a region of size 491 [-Wformat-overflow=]
      sprintf(temp, "[cmplx]# %s", cmdpretty);
                              ^~   ~~~~~~~~~
pretty.c:455:6: note: ‘sprintf’ output between 10 and 509 bytes into a destination of size 500
      sprintf(temp, "[cmplx]# %s", cmdpretty);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pretty.c:461:23: warning: ‘%s’ directive writing up to 499 bytes into a region of size 498 [-Wformat-overflow=]
      sprintf(temp, "# %s", cmdpretty);
                       ^~   ~~~~~~~~~
pretty.c:461:6: note: ‘sprintf’ output between 3 and 502 bytes into a destination of size 500
      sprintf(temp, "# %s", cmdpretty);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Paul Dale]

You will need the Yagarto GCC stuff to build firmware. Nothing else built the code properly.

Have a look in the project's doc direction for a guide to compiling the code.


Pauli

[jpcuzzourt]

(11-24-2019 11:52 AM)Paul Dale Wrote:  You will need the Yagarto GCC stuff to build firmware. Nothing else built the code properly.

Have a look in the project's doc direction for a guide to compiling the code.


Pauli

Thanks! - Especially for pointing me to the compiling instructions. I'd looked for such and missed it there every time.
It's obviously a bigger project than I anticipated, and I probably have better things to spend time on, but I would *like* to get a build environment set up eventually.
I'll start with Yagarto next time I play with it (after I get my nap out. Zzzzz)
On a parallel track, I may try starting where you guys originally did, with the HP-20B SDK, and try to build it up from there, starting with their sample apps.
JP

[Paul Dale]

(11-24-2019 03:14 PM)jpcuzzourt Wrote:  It's obviously a bigger project than I anticipated...

I suspect this reaction is common
It took years of effort.

Quote:I'll start with Yagarto next time I play with it (after I get my nap out. Zzzzz)

Make sure you get the correct version.


Pauli