From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: Kevin Buettner Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] linux-thread.c, lin-thread.c changes Date: Fri, 24 Mar 2000 12:51:00 -0000 Message-id: <38DBD545.14FE@cygnus.com> References: <1000324204825.ZM4807@ocotillo.lan> X-SW-Source: 2000-03/msg00558.html 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 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> 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 To: Jonathan Larmour 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" 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 * 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 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 #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 #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 | | -------------------------------------------------------------------------