This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: [Fwd: [Fwd: gdb 20000413 compile problem and strange SEGVproblem]]
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [Fwd: [Fwd: gdb 20000413 compile problem and strange SEGVproblem]]
- From: Tim Mooney <mooney at dogbert dot cc dot ndsu dot nodak dot edu>
- Date: Thu, 27 Apr 2000 12:56:05 -0500 (CDT)
- cc: GDB Patches <gdb-patches at sourceware dot cygnus dot com>
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