public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
* Re: Does today's gdb compile on Linux?
@ 2000-01-18 13:40 H . J . Lu
       [not found] ` <m3puuy4zy1.fsf@localhost.localnet>
  0 siblings, 1 reply; 6+ messages in thread
From: H . J . Lu @ 2000-01-18 13:40 UTC (permalink / raw)
  To: GNU C Library, Ulrich Drepper

On Tue, Jan 18, 2000 at 12:31:56PM -0700, Kevin Buettner wrote:
> On Jan 18, 10:47am, H . J . Lu wrote:
> > On Tue, Jan 18, 2000 at 11:43:06AM -0700, Kevin Buettner wrote:
> > > On Jan 18, 10:05am, H . J . Lu wrote:
> > > 
> > > > I cannot get today's gdb in CVS to compile on Linux/ia32. It failed on
> > > > i386-linux-nat.c:
> > > > 
> > > > /work/gnu/import/gdb/gdb/i386-linux-nat.c: In function `supply_fpregset':
> > > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:215: request for member `st_space' in
> > > > something not a structure or union
> > > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:217: request for member `cwd' in
> > > > something not a structure or union
> > > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:218: request for member `swd' in
> > > > something not a structure or union
> > > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:219: request for member `twd' in
> > > > something not a structure or union
> > > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:220: request for member `fip' in
> > > > 
> > > > Any ideas?
> > > 
> > > It looks to me like HAVE_PTRACE_GETXFPREGS is getting defined in config.h
> > > when it shouldn't be.
> > 
> > I don't think so.
> > 
> > # grep HAVE_PTRACE_GETXFPREGS config.h
> > /* #undef HAVE_PTRACE_GETXFPREGS */
> 
> My mistake.  I was looking at the wrong section of code.
> 
> i386-linux-nat.c compiles okay for me.
> 
> On my system (a RH6.0 box with few upgrades), I see the following in
> <sys/procfs.h>:
> 
>     typedef elf_fpregset_t fpregset_t;
> 
> In <sys/elf.h>, I see:
> 
>     typedef struct user_fpregs_struct elf_fpregset_t;
> 
> And in <sys/user.h>, I see
> 
>     struct user_fpregs_struct
>     {
>       long cwd;
>       long swd;
>       long twd;
>       long fip;
>       long fcs;
>       long foo;
>       long fos;
>       long st_space [20];
>     };
> 
> Is your system set up differently?
> 
> Kevin

It turned out that the bug was in the current glibc 2.1.3 in CVS.
Ulrich, gregset_t and fpregset_t in <sys/ucontext.h> are different
from the ones in <sys/procfs.h>. The ones in <sys/procfs.h> are used
by gdb and the ptrace system call. They have different sizes and layout
from the ones in <sys/ucontext.h>.



-- 
H.J. Lu (hjl@gnu.org)
---
Tue Jan 18 13:19:14 2000 H.J. Lu  <hjl@gnu.org>

	* sysdeps/unix/sysv/linux/i386/sys/procfs.h: Undo the change
	on 1999-11-02 by Ulrich Drepper  <drepper@cygnus.com>.

Index: sysdeps/unix/sysv/linux/i386/sys/procfs.h
===================================================================
RCS file: /work/cvs/gnu/glibc-2.1/sysdeps/unix/sysv/linux/i386/sys/procfs.h,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 procfs.h
--- sysdeps/unix/sysv/linux/i386/sys/procfs.h	1999/11/27 18:42:39	1.1.1.2
+++ sysdeps/unix/sysv/linux/i386/sys/procfs.h	2000/01/18 21:31:19
@@ -27,7 +27,6 @@
 #include <signal.h>
 #include <sys/time.h>
 #include <sys/types.h>
-#include <sys/ucontext.h>
 #include <sys/user.h>
 #include <sys/elf.h>
 
@@ -40,6 +39,10 @@ struct elf_siginfo
     int si_errno;			/* Errno.  */
   };
 
+typedef elf_greg_t greg_t;
+typedef elf_gregset_t gregset_t;
+typedef elf_fpregset_t fpregset_t;
+#define NGREG ELF_NGREG
 
 /* Definitions to generate Intel SVR4-like core files.  These mostly
    have the same names as the SVR4 types with "elf_" tacked on the

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Does today's gdb compile on Linux?
       [not found] ` <m3puuy4zy1.fsf@localhost.localnet>
@ 2000-01-18 18:11   ` H . J . Lu
  2000-01-18 22:42     ` Jakub Jelinek
  0 siblings, 1 reply; 6+ messages in thread
From: H . J . Lu @ 2000-01-18 18:11 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: GNU C Library

On Tue, Jan 18, 2000 at 05:23:18PM -0800, Ulrich Drepper wrote:
> "H . J . Lu" <hjl@valinux.com> writes:
> 
> 
> No!!!  Use the definitions from ucontext.  Why the hell do you think I
> changed that?  The files procfs.h and ucontext.h must be includable at
> the same time.
> 

The original definitions came from <asm/user.h>. They are used by
ptrace. They are have different meanings than those from ucontext.h. 

It is too bad that the same names, gregset_t and fpregset_t, are used
for different purposes. It is wrong to include ucontext.h in procfs.h
to get "gregset_t" and "fpregset_t". I guess we can modify gdb to use
struct user_fpregs_struct and struct user_regs_struct directly. On the
other hand, it will be tricky to make gdb compile under glibc 2.0, 2.1,
2.2 and libc 5.


-- 
H.J. Lu (hjl@gnu.org)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Does today's gdb compile on Linux?
  2000-01-18 18:11   ` H . J . Lu
@ 2000-01-18 22:42     ` Jakub Jelinek
  2000-01-19 12:19       ` H . J . Lu
  0 siblings, 1 reply; 6+ messages in thread
From: Jakub Jelinek @ 2000-01-18 22:42 UTC (permalink / raw)
  To: H . J . Lu; +Cc: Ulrich Drepper, GNU C Library

On Tue, Jan 18, 2000 at 06:11:47PM -0800, H . J . Lu wrote:
> On Tue, Jan 18, 2000 at 05:23:18PM -0800, Ulrich Drepper wrote:
> > "H . J . Lu" <hjl@valinux.com> writes:
> > 
> > 
> > No!!!  Use the definitions from ucontext.  Why the hell do you think I
> > changed that?  The files procfs.h and ucontext.h must be includable at
> > the same time.
> > 
> 
> The original definitions came from <asm/user.h>. They are used by
> ptrace. They are have different meanings than those from ucontext.h. 
> 
> It is too bad that the same names, gregset_t and fpregset_t, are used
> for different purposes. It is wrong to include ucontext.h in procfs.h
> to get "gregset_t" and "fpregset_t". I guess we can modify gdb to use
> struct user_fpregs_struct and struct user_regs_struct directly. On the
> other hand, it will be tricky to make gdb compile under glibc 2.0, 2.1,
> 2.2 and libc 5.

I saw this as well. I think the right thing is to use i386 configure fragment
for this, which will tell you which one of fpregset_t and elf_fpregset_t you
want to use.

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.39 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Does today's gdb compile on Linux?
  2000-01-18 22:42     ` Jakub Jelinek
@ 2000-01-19 12:19       ` H . J . Lu
       [not found]         ` <m3bt6hzh3r.fsf@localhost.localnet>
  0 siblings, 1 reply; 6+ messages in thread
From: H . J . Lu @ 2000-01-19 12:19 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Ulrich Drepper, GNU C Library

On Wed, Jan 19, 2000 at 07:45:28AM +0100, Jakub Jelinek wrote:
> 
> I saw this as well. I think the right thing is to use i386 configure fragment
> for this, which will tell you which one of fpregset_t and elf_fpregset_t you
> want to use.
> 

Did you mean to change gdb? How about this patch? BTW, we may have
the same gdb problem on all other arches.

-- 
H.J. Lu (hjl@gnu.org)
---
Wed Jan 19 12:15:50 2000 H.J. Lu  <hjl@gnu.org>

	* sysdeps/unix/sysv/linux/i386/sys/procfs.h: Don't include
	<sys/ucontext.h>. Define greg_t, gregset_t, fpregset_t and
	NGREG if _GDB_SOURCE is defined.

Index: sysdeps/unix/sysv/linux/i386/sys/procfs.h
===================================================================
RCS file: /work/cvs/gnu/glibc-2.1/sysdeps/unix/sysv/linux/i386/sys/procfs.h,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 procfs.h
--- sysdeps/unix/sysv/linux/i386/sys/procfs.h	1999/11/27 18:42:39	1.1.1.2
+++ sysdeps/unix/sysv/linux/i386/sys/procfs.h	2000/01/19 20:15:45
@@ -27,7 +27,6 @@
 #include <signal.h>
 #include <sys/time.h>
 #include <sys/types.h>
-#include <sys/ucontext.h>
 #include <sys/user.h>
 #include <sys/elf.h>
 
@@ -40,6 +39,15 @@ struct elf_siginfo
     int si_errno;			/* Errno.  */
   };
 
+#ifdef _GDB_SOURCE
+/* They are used by gdb. We cannot use the ones in <sys/ucontext.h>
+   since they are different. It is too bad the same things are used
+   for different things. But it is hard to change now. */
+typedef elf_greg_t greg_t;
+typedef elf_gregset_t gregset_t;
+typedef elf_fpregset_t fpregset_t;
+#define NGREG ELF_NGREG
+#endif
 
 /* Definitions to generate Intel SVR4-like core files.  These mostly
    have the same names as the SVR4 types with "elf_" tacked on the

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Does today's gdb compile on Linux?
       [not found]         ` <m3bt6hzh3r.fsf@localhost.localnet>
@ 2000-01-20  6:22           ` H . J . Lu
       [not found]             ` <m366wowaxv.fsf@localhost.localnet>
  0 siblings, 1 reply; 6+ messages in thread
From: H . J . Lu @ 2000-01-20  6:22 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: Jakub Jelinek, GNU C Library

On Wed, Jan 19, 2000 at 05:06:48PM -0800, Ulrich Drepper wrote:
> "H . J . Lu" <hjl@valinux.com> writes:
> 
> > Did you mean to change gdb? How about this patch? BTW, we may have
> > the same gdb problem on all other arches.
> 
> No, no, no.  ucontext.h has to be included and keep the gdb crap out
> of the system headers.  Fix the gdb sources.
> 

I created <sys/procfs.h> for bfd and gdb. Now you changed the meanings
of those types I created in <sys/procfs.h>, no matter how inappropriate
they were. At least, you should provide a way at the C preprocesser
level for bfd and gdb to tell that they are changed. It is very
irresponsible for you not to do so. Basically, what you did is change
API in <sys/procfs.h>. Please fix it.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Does today's gdb compile on Linux?
       [not found]             ` <m366wowaxv.fsf@localhost.localnet>
@ 2000-01-20 21:50               ` H . J . Lu
  0 siblings, 0 replies; 6+ messages in thread
From: H . J . Lu @ 2000-01-20 21:50 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: Jakub Jelinek, GNU C Library

On Thu, Jan 20, 2000 at 04:00:28PM -0800, Ulrich Drepper wrote:
> "H . J . Lu" <hjl@valinux.com> writes:
> 
> > I created <sys/procfs.h> for bfd and gdb. Now you changed the meanings
> > of those types I created in <sys/procfs.h>, no matter how inappropriate
> > they were. At least, you should provide a way at the C preprocesser
> > level for bfd and gdb to tell that they are changed. It is very
> > irresponsible for you not to do so. Basically, what you did is change
> > API in <sys/procfs.h>. Please fix it.
> 
> The solution was already lined out: use the elf_* types in gdb.  These
> are the types you actually want and not the pr* types.  Linux does not
> have the pr* interface and so gdb provides it itself and here the
> types assumed are those which are currently defined.
> 

I am not sure if elf_* types available for libc 5, glibc 2.0 and
glibc 2.1. gdb need something to tell that elf_* types should be
used.

-- 
H.J. Lu (hjl@gnu.org)

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2000-01-20 21:50 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-01-18 13:40 Does today's gdb compile on Linux? H . J . Lu
     [not found] ` <m3puuy4zy1.fsf@localhost.localnet>
2000-01-18 18:11   ` H . J . Lu
2000-01-18 22:42     ` Jakub Jelinek
2000-01-19 12:19       ` H . J . Lu
     [not found]         ` <m3bt6hzh3r.fsf@localhost.localnet>
2000-01-20  6:22           ` H . J . Lu
     [not found]             ` <m366wowaxv.fsf@localhost.localnet>
2000-01-20 21:50               ` H . J . Lu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).