From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Jelinek To: Jim Kingdon Cc: robertl@sco.com, jimb@cygnus.com, gdb-patches@sourceware.cygnus.com, davem@redhat.com Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB] Date: Mon, 01 Nov 1999 13:08:00 -0000 Message-id: <19991101221044.Z525@mff.cuni.cz> References: <199911010048.TAA07679@devserv.devel.redhat.com> <19991101110509.O19769@rjlhome.sco.com> <199911011742.MAA28800@devserv.devel.redhat.com> X-SW-Source: 1999-q4/msg00140.html On Mon, Nov 01, 1999 at 12:42:23PM -0500, Jim Kingdon wrote: > > From what I recall, sys/ptrace.h and one of the GDB headers were each > > trying to outsmart the other. > > No, it is two system headers. /usr/include/asm-sparc/ptrace.h > (included via a dizzying cascade of includes from > /usr/include/signal.h) and /usr/include/sys/ptrace.h. The former > contains "#define PTRACE_GETREGS 12" and the latter has an enum which > contains "PTRACE_GETREGS = 12". > > DaveM, Jakub, let's get this fixed. We've been kludging around it in > GDB long enough. I hope this is already fixed, at least I hacked on it. But it is in 2.3.* kernel headers and glibc 2.1.90 CVS, but I can backport it if needed. Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj Linux version 2.3.18 on a sparc64 machine (1343.49 BogoMips) ___________________________________________________________________ >From shebs@cygnus.com Mon Nov 01 13:27:00 1999 From: Stan Shebs To: tromey@cygnus.com Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Patch: --enable-profiling Date: Mon, 01 Nov 1999 13:27:00 -0000 Message-id: <199911012127.NAA17713@andros.cygnus.com> References: <199910311504.HAA00905@ferrule.cygnus.com> X-SW-Source: 1999-q4/msg00141.html Content-length: 1039 Date: Sun, 31 Oct 1999 07:04:57 -0800 (PST) From: Tom Tromey Stan> BTW, will this work with djgpp and/or cygwin? What will happen Stan> if you try to configure on those with --enabling-profiling? It might work or it might not. I don't know. My theory is that profiling gdb is a maintainer thing, and if somebody uses --enable-profiling and it doesn't build, they had better know what they are doing anyway. We can always add tests for functions later. I could add them now if it is important; it is easy enough to do. Ordinarily I'm zealous about portability, but in this case I don't think it matters that much. If it's not going to work, or as cgf suggests, it won't be very interesting, it's worth just having a note in the docs to that effect. Internals manual only is sufficient. Even a knowledgeable person, using this for the first time, will be hard-pressed to know whether the failure to build/run is a known limitation, or something wrong in the setup. Stan