Re: [Fwd: [Fwd: gdb 20000413 compile problem and strange SEGVproblem]]

[Tim Mooney <mooney at dogbert dot cc dot ndsu dot nodak dot edu>]

In regard to: Re: [Fwd: [Fwd: gdb 20000413 compile problem and strange...:

>> I don't think so.  I just checked with both ANSI (-std1) and ANSI+extensions
>> (-std) and in both cases the 4.0f compiler still objects to the comparisons.
>> 
>> I've been known to be wrong, but my feeling is that the compiler is actually
>> correct.  Based on my reading of K&R 2e (section 5.4, page 103, last paragraph
>> which begins "The valid pointer operations are..."), casting `tcomplain' to
>> `void *' is not enough to allow pointer comparison.
>
>Yes, the compiler is right.  Just pig-headed :-)


:-) No argument here.


>> Is there a reason why changing the cast as I mentioned in my original
>> message is unacceptable?
>
>No.  I'm just trying to figure out how much damage there is going to be.

Good enough.

>> Thanks, I got all 67 Meg of gdb+dejagnu :-), but decided to try the
>> gdb-4.95.0 snapshot instead, and the problem still exists in that snapshot.
>> Trying to build that on 4.0f fails in target.c.
>
>Could you force the compilation to continue and see if there are any
>other errors.

After fixing the pointer comparison problem so the build will continue on
the alpha, I verified that the build completes on

	alpha-dec-osf4.0f
	hppa1.1-hp-hpux10.20
	powerpc-ibm-aix4.3.2.0
	sparc-sun-solaris2.6

The build never even gets that far on

	mips-sgi-irix6.5

(6.5.5 actually -- I'm surprised the real OS version isn't used, instead
of just the "base version" of "6.5").  I'm compiling with the MIPSPro 7.2.x
vendor compiler, in `-n32' mode (new 32-bit ABI, which is the default on
many/most IRIX platforms these days).  It fails in `procfs.c', with:

cc-1515 cc: ERROR File = procfs.c, Line = 2603
  A value of type "CORE_ADDR" cannot be assigned to an entity of type "caddr_t".

    pwatch->pr_vaddr  = addr;
                      ^

pwatch->pr_vaddr is of type caddr_t (a pointer), CORE_ADDR is typedef'ed to
bfd_vma in defs.h, bfd_vma appears to be an `unsigned long long' (from bfd.h).

If I remove `procfs.o' from the list of objects to build and re-make, I get
an immediate error on proc-api.c:

cc -c -n32 -xansi    -I. -I. -I./config -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd  -I./../include -I../intl -I./../intl -I./tui  -DUSE_INCLUDED_REGEX   proc-api.c
cc-1005 cc: ERROR File = proc-api.c, Line = 39
  The source file "sys/user.h" is unavailable.

  #include <sys/user.h> /* for struct user */
                                             ^

Looks like that's something that needs to be checked for with `configure'.

Removing that as well, the build proceeds until the link stage, which obviously
fails because of the object files I've skipped.

Note: I've only tested the builds, I haven't done any test on how well the
debugger works on any particular platform...

Tim
-- 
Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J1, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164