From: "Peter.Schauer" <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE>
To: meyering@eng.ascend.com (Jim Meyering)
Cc: gdb-patches@cygnus.com
Subject: Re: gdb-970817 vs i386-pc-solaris2.5.1
Date: Sat, 27 Sep 1997 14:32:00 -0000 [thread overview]
Message-ID: <199709272131.XAA19911@red.regent.e-technik.tu-muenchen.de> (raw)
In-Reply-To: <yzqn2ky7i4u.fsf@boom.eng.ascend.com>
GDB is not supported on ix86/solaris, and I do not have access
to a ix86/solaris system, so I can't comment on the first two patches.
(I suspect however that a better solution would be to create a new
config/i386/tm-i386sol2.h file, which gets used by i386sol2.mt, includes
tm-i386v4.h and adds the TIDGET definition from config/sparc/tm-sun4sol2.h).
The linker problem happens if you use gcc and the native ld.
A simple workaround for now is to remove
-Xlinker -export-dynamic
by hand from the INTERNAL_LDFLAGS in gdb/Makefile.
> Hi,
>
> I have the misfortune to run solaris2.5.1 on my nice dual P200 Vectra.
> I tried to build gdb-970817 using this version of egcs:
>
> Reading specs from /p/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.06/specs
> gcc version egcs-2.90.06 970907 (gcc2-970802 experimental)
>
> My first compile failed because neither R_PSR nor PS_FLAG_CARRY was defined.
> Here's a kludge to work around that.
>
> --- procfs.c.orig Sat Sep 27 12:22:02 1997
> +++ procfs.c Sat Sep 27 12:21:50 1997
> @@ -5218,6 +5218,7 @@ procfs_lwp_creation_handler (pi, syscall
> /* If lwp_create failed, then nothing interesting happened. Continue the
> process and go back to sleep. */
>
> +#if defined (R_PSR) && defined (PS_FLAG_CARRY)
> if (pi->prstatus.pr_reg[R_PSR] & PS_FLAG_CARRY)
> { /* _lwp_create failed */
> pi->prrun.pr_flags &= PRSTEP;
> @@ -5228,6 +5229,7 @@ procfs_lwp_creation_handler (pi, syscall
>
> return 0;
> }
> +#endif
>
> /* At this point, the new thread is stopped at it's first instruction, and
> the parent is stopped at the exit from lwp_create. */
>
>
> Next attempt failed because TIDGET is not defined and hence,
> procfs_pid_to_str (used below) is not defined. Here's the really ugly
> kludge I used to work around that.
>
> --- sol-thread.c.orig Sat Sep 27 12:21:09 1997
> +++ sol-thread.c Sat Sep 27 12:20:38 1997
> @@ -121,7 +121,11 @@ static int sol_thread_alive PARAMS ((int
> #define THREAD_FLAG 0x80000000
> #define is_thread(ARG) (((ARG) & THREAD_FLAG) != 0)
> #define is_lwp(ARG) (((ARG) & THREAD_FLAG) == 0)
> +#ifdef TIDGET
> #define GET_LWP(LWP_ID) (TIDGET(LWP_ID))
> +#else
> +# define GET_LWP(LWP_ID) 1 /* Kludge!! */
> +#endif
> #define GET_THREAD(THREAD_ID) (((THREAD_ID) >> 16) & 0x7fff)
> #define BUILD_LWP(LWP_ID, PID) ((LWP_ID) << 16 | (PID))
> #define BUILD_THREAD(THREAD_ID, PID) (THREAD_FLAG | BUILD_LWP (THREAD_ID, PID))
> @@ -1213,9 +1217,11 @@ solaris_pid_to_str (pid)
> {
> static char buf[100];
>
> +#ifdef TIDGET
> /* in case init failed to resolve the libthread_db library */
> if (!procfs_suppress_run)
> return procfs_pid_to_str (pid);
> +#endif
>
> if (is_thread (pid))
> {
>
> Finally, I got this (inexplicable to me) link error:
>
> ...
> te.o main.o inflow.o gnu-regex.o ../bfd/libbfd.a ../readline/libreadline.a ../opcodes/libopcodes.a ../libiberty/libiberty.a -ltermlib -ldl -lm ../mmalloc/libmmalloc.a ../libiberty/libiberty.a
> ld: fatal: entry point symbol `xport-dynamic' is undefined
> collect2: ld returned 1 exit status
> make[1]: *** [gdb] Error 1
> make[1]: Leaving directory `/tmp/gdb-970817/gdb'
> make: *** [all-gdb] Error 2
> [Exit 2]
>
>
--
Peter Schauer pes@regent.e-technik.tu-muenchen.de
next prev parent reply other threads:[~1997-09-27 14:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-09-27 10:59 Jim Meyering
1997-09-27 14:32 ` Peter.Schauer [this message]
1997-10-05 6:21 ` Jim Meyering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199709272131.XAA19911@red.regent.e-technik.tu-muenchen.de \
--to=peter.schauer@regent.e-technik.tu-muenchen.de \
--cc=gdb-patches@cygnus.com \
--cc=meyering@eng.ascend.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox