* Re: [PATCH RFA] linux-thread.c, lin-thread.c changes
2000-03-24 12:48 [PATCH RFA] linux-thread.c, lin-thread.c changes Kevin Buettner
@ 2000-03-24 12:51 ` Michael Snyder
0 siblings, 0 replies; 2+ messages in thread
From: Michael Snyder @ 2000-03-24 12:51 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
Kevin Buettner wrote:
>
> I request approval for committing the changes below.
Looks good to me. Thanks. Commit away.
>
> The lines that read
>
> #if TARGET_PTR_BIT > TARGET_INT_BIT
>
> cause a compilation error on linux/ia64 due to the fact that
> TARGET_PTR_BIT and TARGET_INT_BIT are computed at runtime for the
> IA-64 architecture. (When we get around to multi-arching the other
> linux ports, they'll have the same problem.)
>
> * linux-thread.c, lin-thread.c (save_inferior_pid,
> restore_inferior_pid): Don't do compile time comparison
> of TARGET_PTR_BIT and TARGET_INT_BIT.
>
> Index: linux-thread.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/linux-thread.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 linux-thread.c
> --- linux-thread.c 2000/03/18 01:56:31 1.5
> +++ linux-thread.c 2000/03/24 20:36:43
> @@ -378,25 +378,22 @@ linuxthreads_find_trap (pid, stop)
>
> /* Cleanup stub for save_inferior_pid. */
> static void
> -restore_inferior_pid (arg)
> - void *arg;
> +restore_inferior_pid (void *arg)
> {
> -#if TARGET_PTR_BIT > TARGET_INT_BIT
> - inferior_pid = (int) ((long) arg);
> -#else
> - inferior_pid = (int) arg;
> -#endif
> + int *saved_pid_ptr = arg;
> + inferior_pid = *saved_pid_ptr;
> + free (arg);
> }
>
> /* Register a cleanup to restore the value of inferior_pid. */
> static struct cleanup *
> -save_inferior_pid ()
> +save_inferior_pid (void)
> {
> -#if TARGET_PTR_BIT > TARGET_INT_BIT
> - return make_cleanup (restore_inferior_pid, (void *) ((long) inferior_pid));
> -#else
> - return make_cleanup (restore_inferior_pid, (void *) inferior_pid);
> -#endif
> + int *saved_pid_ptr;
> +
> + saved_pid_ptr = xmalloc (sizeof (int));
> + *saved_pid_ptr = inferior_pid;
> + return make_cleanup (restore_inferior_pid, saved_pid_ptr);
> }
>
> static void
> Index: lin-thread.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/lin-thread.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 lin-thread.c
> --- lin-thread.c 2000/02/09 08:52:46 1.2
> +++ lin-thread.c 2000/03/24 20:36:47
> @@ -658,21 +658,19 @@ init_thread_db_library ()
> static struct cleanup *
> save_inferior_pid (void)
> {
> -#if TARGET_PTR_BIT > TARGET_INT_BIT
> - return make_cleanup (restore_inferior_pid, (void *) ((long) inferior_pid));
> -#else
> - return make_cleanup (restore_inferior_pid, (void *) inferior_pid);
> -#endif
> + int *saved_pid_ptr;
> +
> + saved_pid_ptr = xmalloc (sizeof (int));
> + *saved_pid_ptr = inferior_pid;
> + return make_cleanup (restore_inferior_pid, saved_pid_ptr);
> }
>
> static void
> -restore_inferior_pid (void *saved_pid)
> +restore_inferior_pid (void *arg)
> {
> -#if TARGET_PTR_BIT > TARGET_INT_BIT
> - inferior_pid = (int) ((long) saved_pid);
> -#else
> - inferior_pid = (int) saved_pid;
> -#endif
> + int *saved_pid_ptr = arg;
> + inferior_pid = *saved_pid_ptr;
> + free (arg);
> }
>
> /*
From kevinb@cygnus.com Fri Mar 24 13:11:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] linux-thread.c, lin-thread.c changes
Date: Fri, 24 Mar 2000 13:11:00 -0000
Message-id: <1000324211045.ZM4912@ocotillo.lan>
References: <1000324204825.ZM4807@ocotillo.lan> <38DBD545.14FE@cygnus.com> <msnyder@cygnus.com>
X-SW-Source: 2000-03/msg00559.html
Content-length: 385
On Mar 24, 12:51pm, Michael Snyder wrote:
> Kevin Buettner wrote:
> >
> > I request approval for committing the changes below.
>
> Looks good to me. Thanks. Commit away.
[snip]
> > * linux-thread.c, lin-thread.c (save_inferior_pid,
> > restore_inferior_pid): Don't do compile time comparison
> > of TARGET_PTR_BIT and TARGET_INT_BIT.
[snip]
Committed.
From fnasser@cygnus.com Fri Mar 24 13:18:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Jonathan Larmour <jlarmour@redhat.com>
Cc: fnasser@redhat.com, gdb-patches@sourceware.cygnus.com
Subject: Re: thumb_skip_prologue too adventurous
Date: Fri, 24 Mar 2000 13:18:00 -0000
Message-id: <38DBDB89.56D0049A@cygnus.com>
References: <38D3FFC8.32082A85@redhat.co.uk> <38D40052.AF731E81@redhat.co.uk> <38D5064B.40AE9470@redhat.com> <200003242046.UAA14702@murgh.cygnus.co.uk>
X-SW-Source: 2000-03/msg00560.html
Content-length: 484
Jonathan Larmour wrote:
>
> I now have checkin rights. Is it therefore okay for me to check the thumb
> patch in?
>
> And add the new test below? [ left included in its entirety ]
>
Sure, go for it. It is one less item in this endless list I have here...
Thanks.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From phdm@macqel.be Fri Mar 24 13:51:00 2000
From: "Philippe De Muyter" <phdm@macqel.be>
To: gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com), dan@cgsoftware.com
Subject: regerror link error
Date: Fri, 24 Mar 2000 13:51:00 -0000
Message-id: <200003242151.WAA07612@mail.macqel.be>
X-SW-Source: 2000-03/msg00561.html
Content-length: 845
The following patch :
2000-03-22 Daniel Berlin <dan@cgsoftware.com>
* command.c (apropos_cmd_helper): New function, meat of the
apropos command.
(apropos_command): New apropos command to search command
names/documentation for regular expressions.
(_initialize_command): Add the apropos command.
makes the compilation of gdb fail on my system (m68k-motorola-sysv) :
gcc -g -O2 -W -Wall -o gdb main.o libgdb.a ../bfd/libbfd.a ../readline
/libreadline.a ../opcodes/libopcodes.a ./../intl/libintl.a ../libiberty/libibert
y.a -lncurses -lm ../libiberty/libiberty.a
libgdb.a(command.o): In function `apropos_command':
command.c:481: undefined reference to `regerror'
collect2: ld returned 1 exit status
Actually, I have found a __regerror, but no regerror. How can we fix that ?
Philippe
From john@feith.com Fri Mar 24 14:00:00 2000
From: John Wehle <john@feith.com>
To: eliz@delorie.com
Cc: jimb@zwingli.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: GDB 4.17 Patch for stack aligned i386 code
Date: Fri, 24 Mar 2000 14:00:00 -0000
Message-id: <200003242200.RAA13376@jwlab.FEITH.COM>
X-SW-Source: 2000-03/msg00562.html
Content-length: 3601
> Is it possible to tell a bit more about the problem, and how is it
> solved?
It's desirable to omit the frame pointer when compiling leaf functions
when targeting the x86 processor as this provides another hard register
(%ebp) which can be used by the register allocators. Using
-momit-leaf-frame-pointer instructs GCC to compile code in this manner.
Unfortunately GDB has a rather strong belief that %ebp always points to
the frame and is unable to locate function arguments or local variables
when the frame pointer is omitted. The changes allow GDB to locate the
frame based on the value in %esp.
> Perhaps even a short test case, before and after the change?
An example is backtracing through sigtramps on Solaris (the Solaris library
contains functions which don't use %ebp as the frame pointer). For example
... the backtrace from gdb.base/a1-selftest.exp (without my patch) shows:
#0 0x80068745 in _libc_sigprocmask ()
#1 0x80098763 in sigprocmask ()
#2 0x8107cb3 in rl_signal_handler (sig=134509072) at signals.c:156
#3 0x800685b1 in _sigacthandler ()
#4 <signal handler called>
#5 0x800682b8 in _libc_read ()
#6 0x8101ef9 in rl_getc (stream=0x800a9ad4) at readline.c:3123
#7 0x80ffa5b in rl_read_key () at readline.c:578
The correct backtrace is:
#0 0x80068745 in _libc_sigprocmask ()
#1 0x80098763 in sigprocmask ()
#2 0x8107fe7 in rl_signal_handler (sig=134509096) at signals.c:156
#3 0x800685b1 in _sigacthandler ()
#4 <signal handler called>
#5 0x800682b8 in _libc_read ()
#6 0x80098b33 in read ()
#7 0x810222d in rl_getc (stream=0x81639a0) at readline.c:3123
#8 0x80ffd8f in rl_read_key () at readline.c:578
> Also, do the original problems affect Solaris alone, or are they
> common to all gcc/x86-based architectures?
They're common to all gcc/x86-based architectures.
> It's quite difficult to judge a large patch for two different problems
> without having a more-or-less clear notion of the issues involved.
Actually they're slight variations of same problem which is how to locate
the frame. The GDB patch in question supports locating the frame for x86
code:
1) In a leaf function where the frame pointer has been omitted. GCC
currently supports generating this if -momit-leaf-frame-pointer is
specified. It's desirable to make this the default once debugging
support is in place.
2) In a function where the frame pointer has been omitted and the stack
pointer is unchanging. For example:
int global;
void
unchanging_sp(int a, int b)
{
global = a + b;
print_global();
}
I have a patch for GCC to support omitting the frame pointer in this
case which has been delayed pending debugger support. It's desirable
to also have this as part of the default x86 code generation strategy.
3) In a function where "andl" has been used to align the frame. I have
an experimental patch for GCC to support aligning the frame in this
fashion in order to improve x86 floating point performance.
The original GDB work was done in November 1998 and January 1999. I'd be
happy to dust things off on my side in order to get these changes installed
if you're interested in working with me. BTW, the necessary paperwork
is already on file.
-- John
-------------------------------------------------------------------------
| Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com |
| John Wehle | Fax: 1-215-540-5495 | |
-------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 2+ messages in thread