Shop OBEX P1 Docs P2 Docs Learn Events
Porting binutils to the new P2 — Parallax Forums

Porting binutils to the new P2

I'm starting to look at porting PropGCC to P2. I mean, to generate P2 code not to actually *run* on P2. In any case, I'm running into my usual problem that Xcode on the Macintosh is overly picky about C code and GCC's build system compiles with -Werror. This means that any warning is treated as an error. My current problem has to do with arguments to printf. I get the following error when trying to build binutils:
gcc -Wno-string-plus-int -Wno-deprecated-declarations -Wno-empty-body -Wno-self-assign -Wno-sometimes-uninitialized -Wno-uninitialized -Wno-unknown-warning-option -Wno-unused-function -Wno-format -Wno-format-signedness   -I. -I../../binutils-propeller/gdb -I../../binutils-propeller/gdb/common -I../../binutils-propeller/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../binutils-propeller/gdb/../include/opcode -I../../binutils-propeller/gdb/../opcodes/.. -I../../binutils-propeller/gdb/../readline/.. -I../../binutils-propeller/gdb/../zlib -I../bfd -I../../binutils-propeller/gdb/../bfd -I../../binutils-propeller/gdb/../include -I../libdecnumber -I../../binutils-propeller/gdb/../libdecnumber -I./../intl -I../../binutils-propeller/gdb/gnulib/import -Ibuild-gnulib/import   -DTUI=1  -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wpointer-sign -Wmissing-prototypes -Wdeclaration-after-statement -Wmissing-parameter-type -Wold-style-declaration -Wold-style-definition -Wformat-nonliteral -Werror -c -o darwin-nat.o -MT darwin-nat.o -MMD -MP -MF .deps/darwin-nat.Tpo ../../binutils-propeller/gdb/darwin-nat.c
../../binutils-propeller/gdb/darwin-nat.c:258:30: error: format specifies type 'unsigned int' but the argument has type 'caddr_t'
      (aka 'char *') [-Werror,-Wformat]
                  name, pid, arg3, arg4, ret,
                             ^~~~

Usually, I fix this sort of problem by adding a compiler option to ignore the warning. However, that didn't work in this case. You can see that the options -Wno-format and -Wno-format-signedness are specified on the gcc command line but I still get these warnings. Does anyone know a way around this?

Comments

  • This might be an actual bug. Looks like the format string in a printf-like function call is "%u" whereas arg3 is a caddr_t, and caddr_t is a char *. If you change the %u in the format string to %s it should go away unless I'm mistaken.

    It's always better to fix warnings in code instead of just shoving them under the mat...

    ===Jac

  • This might be an actual bug. Looks like the format string in a printf-like function call is "%u" whereas arg3 is a caddr_t, and caddr_t is a char *. If you change the %u in the format string to %s it should go away unless I'm mistaken.

    It's always better to fix warnings in code instead of just shoving them under the mat...

    ===Jac
    I agree except that this is GCC generic code. It isn't my code and there are literally thousands of warnings. Apparently, not everyone shares our philosophy. Actually, GCC normally compiles with -Werror so you would think that would mean that there would be no warnings at all. The problem is, the Xcode compiler is a lot pickier than the ones the developers must have used because I have to turn off lots of warnings just to get anything to compiler. In this case, it looks like I may need to turn them all off. :-(

  • The source from your github repository looks a bit different from what it is possible to deduce from the warning. In your source, arg3 is defined as PTRACE_TYPE_ARG3 (which is defined from the configure process, if I'm not wrong) and caddr_t is used in the ptrace call and not the inferior_debug call where the warning seems to originate. The call to ptrace looks correct since it requires a void * arg, and the printf-like call looks also correct. Have you changed the PTRACE_TYPE_ARG3 definition ? if so try to set it to long if you are on 64bit or int if on 32bit.
  • Thanks for the advice. I'll check the definition of PTRACE_TYPE_ARG3 for Macintosh compiles.
Sign In or Register to comment.