Re: [RFA/RFC] fix problems with unwinder on mips-irix

Andrew,

> Yes, sometimes inlineing doesn't help, here it does.  There's really no 
> value in trying to preserve this code so be brutal.

Thanks a lot for the detailed message. Really appreciated. I'm trying to
find my way through all this. Let's first look at inlining find_proc_desc.
I'll work on the rest as soon as I have this one figured out.

Reading your last commit to this file, I discovered that you added frame
sniffers, so, if I understand correctly, we can now more or less predict
the circumstances under which find_proc_desc should be called (heuristic
vs non-heuristic). Is that right?

find_proc_desc is called by 4 routines:

  1. mips_mdebug_frame_cache

      /* Get the mdebug proc descriptor.  */
      proc_desc = find_proc_desc (frame_pc_unwind (next_frame), next_frame, 1);

     In that case, I think this call can be replaced by a call to
     non_heuristic_proc_desc? How about the handling this case:

      /* IF this is the topmost frame AND
       * (this proc does not have debugging information OR
       * the PC is in the procedure prologue)
       * THEN create a "heuristic" proc_desc (by analyzing
       * the actual code) to replace the "official" proc_desc.
       */

[patch] Add comment in config/powerc/aix.mh

This is in preparation for the merging of aix.mh and aix432.mh.
this change makes these 2 files identical (except for formatting).

2004-08-31  Joel Brobecker  <brobecker <at> gnat.com>

        * config/powerpc/aix.mh: Add comment.

Checked in.
-- 
Joel

Index: aix.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/aix.mh,v
retrieving revision 1.7
diff -u -p -r1.7 aix.mh
--- aix.mh	12 Aug 2004 06:28:11 -0000	1.7
+++ aix.mh	1 Sep 2004 00:00:33 -0000
 <at>  <at>  -1,6 +1,8  <at>  <at> 
 # Host: IBM PowerPC running AIX

 NAT_FILE= nm-aix.h
+
+# aix-thread.o is not listed in NATDEPFILES as it is pulled in by configure.
 NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o rs6000-nat.o \
 	     xcoffread.o xcoffsolib.o

[RFA/PATCH] Delete config/rs6000/xm-rs6000.h

I think we can safely remove this xm file. This was discussed in

        http://sources.redhat.com/ml/gdb-patches/2004-08/msg00462.html

In the message above, Andrew said:
> >Hmm, sorry, my fault. Can I ask again, just to make sure I am not
> >misinterpreting you: This is a configuration I can not test - we
> >should be able to remove blindly these xm­ files without breaking
> >anything, but since I can't test them, it may break. Should we go
> >ahead now anyway?
> 
> Correct.  We can't reasonably require you or anyone else to test on such
> extremely old configurations.  Instead we go with the working assumption
> that the new code is sufficient to replace the old.

I'll commit the patch below in a day or two, unless somebody objects.
For your convenience, I am also attaching a copy of the current
xm-rs6000.h file, to let you see what we're removing.

2004-08-31  Joel Brobecker  <brobecker <at> gnat.com>

        * config/rs6000/xm-rs6000.h: Remove this file.
        * config/rs6000/rs6000.mh (XM_FILE): Remove.

** UNTESTED **

--

-- 
Joel

[RFA/PATCH] Delete config/rs6000/xm-aix4.h

With xm-rs6000.h, this is the last xm-file!!! It's just a tiny winny
less obvious why we can remove this file. Here is its contents:

  /* AIX 4.x uses nonstandard "int *" as type of third argument to ptrace() */

  #define PTRACE_ARG3_TYPE int*

This macro is used in infptrace. There is a new mechanism in configure
that finds the type of argument 3 of ptrace, and sets PTRACE_TYPE_ARG3.

And then we have the following magic code in inferior.h:

        #ifndef PTRACE_ARG3_TYPE
        #define PTRACE_ARG3_TYPE PTRACE_TYPE_ARG3
        #endif

A grep for PTRACE_ARG3_TYPE on all .h files in gdb yields:

        config/alpha/nm-osf.h:#define PTRACE_ARG3_TYPE int*
        config/mips/nm-linux.h:#define PTRACE_ARG3_TYPE long
        config/nm-lynx.h:#define PTRACE_ARG3_TYPE int
        config/pa/nm-hppah.h:#define PTRACE_ARG3_TYPE CORE_ADDR
        config/powerpc/nm-aix.h:#define PTRACE_ARG3_TYPE int*
        config/powerpc/nm-ppc64-linux.h:#define PTRACE_ARG3_TYPE void *
        config/rs6000/xm-aix4.h:#define PTRACE_ARG3_TYPE int*
        config/s390/nm-linux.h:#define PTRACE_ARG3_TYPE long
        config/sparc/nm-linux.h:#define PTRACE_ARG3_TYPE long
        inferior.h:#ifndef PTRACE_ARG3_TYPE
        inferior.h:#define PTRACE_ARG3_TYPE PTRACE_TYPE_ARG3
        inferior.h:extern int call_ptrace (int, int, PTRACE_ARG3_TYPE, int);

Re: [rfa/gdb.threads] Test static thread program

Andrew Cagney wrote:
>> Andrew Cagney wrote:
>>
>>>> I really really appreciate the contribution of a static thread test.
>>>> I'd like to know what specific failure mode(s) you're looking for.
>>>
>>>
>>>
>>>
>>> GDB's thread debugging does not work on GNU/Linux when the program is 
>>> linked statically.
>>
>>
>>
>> Well yes, I guessed that much.  Can you be more specific?
> 
> 
> Bug 1328 contains all the information I know, which at present isn't 
> much (I'm guessing that it is missing a thread library loaded event). 
> I've attached a gdb.log.

All right, then since you're unwilling to do any non-linux testing,
please check it in, and we'll deal with any problems if they come up.

Re: [RFA]: Change to_stopped_data_address ABI

> Date: Tue, 31 Aug 2004 16:18:29 -0400
> From: Jeff Johnston <jjohnstn <at> redhat.com>
> Cc: gdb-patches <at> sources.redhat.com
> 
> Perhaps my description isn't clear enough.  The function returns non-zero if 
> successful (i.e. true).  It returns 0 (false) to indicate failure or no stopped 
> data address.

Well, I understood that, I think; but the code you posted seems to
work differently: if no watchpoint triggered, it returns 1, not zero:

> >> <at>  <at>  -593,7 +598,16  <at>  <at>  i386_stopped_data_address (void)
> >>   if (maint_show_dr && addr == 0)
> >>     i386_show_dr ("stopped_data_addr", 0, 0, hw_write);
> >> 
> >>-  return addr;
> >>+  *addr_p = addr;
> >>+  return 1;

Thus, in the case of "no stopped data address",
i386_stopped_data_address will return 1 with 0 in the place pointed to
by its argument, is that right?

Re: [RFA]: Java Inferior Call Take 3

Jeff Johnston <jjohnstn <at> redhat.com> writes:
> Here is the revised patch.
> 
> 2004-08-24  Jeff Johnston  <jjohnstn <at> redhat.com>
> 
>      * dwarf2read.c (typename_concat): Change prototype to accept dwarf2_cu
>      struct pointer as argument.  Change function to use new argument to
>      determine language.  If language is Java, use "." as separator,
>      otherwise, use "::".
>      (partial_die_parent_scope): Change comment to include java.  Check
>      language to determine if Java "." or C++ "::" separator should be used.
>      (add_partial_symbol): Enhance tests for C++ to also test for Java.
>      (guess_structure_name): Ditto.
>      (read_subroutine_type): Ditto.
>      (new_symbol): Ditto.
>      (read_structure_type): Add Java vtable support.
>      (read_namespace): Add Java support.
>      * jv-exp.y (FuncStart): New pattern.
>      (MethodInvocation): Add support for simple function calls.  Change
>      warning message for other forms of inferior call currently not
>      supported.
>      * valarith.c (value_subscript): Treat an array with upper-bound
>      of -1 as unknown size.

For the dwarf2read.c part of this patch:

There are a lot of places where we're selecting the name component
separator based on the language; I'd like compound name construction
abstracted out into its own function.  Two possible approaches:

Porting h8300 - gdb frame to new frame code

Hi,
 Reference:http://sources.redhat.com/ml/gdb-patches/2004-07/msg00185.html

  I am in the task of porting h8300 to new frame structure. I have taken the ported 
"Sh" frame code as a reference for "h8300" porting.

I have introduced the new frame related functions as shown in the patch below.

Also the following function has been modified:
   h8300_examine_prologue

But while executing the command "info f" I am getting wrong location of args and locals 
(i.e. it is giving the location as the location of sp, where as is it should be the location 
of frame). I have changed only the "get_frame_base " argument in "h8300_examine_prologue" to 
the cache->base as it would be the location of stack address. 

Is it due to the fact that the generated dwarf 2 information for H8300 is not correct?

Any help in this regard will be appreciated.

===========================================================================================
--- gdb-6.2/gdb/h8300-tdep-old.c	2004-06-20 22:48:05.000000000 +0530
+++ gdb-6.2/gdb/h8300-tdep.c	2004-08-31 19:01:09.000000000 +0530
 <at>  <at>  -37,11 +37,12  <at>  <at> 
 #include "gdb_assert.h"
 #include "dis-asm.h"

-/* Extra info which is saved in each frame_info. */
-struct frame_extra_info
-{

[RFA/testsuite]: gdb.base/call-rt-st.exp: Fix typo

Hi,

call-rt-st.exp contains two typos which result in testing against the wrong
datatype.  Patch tested on Linux natively and on linux-x-sh-elf BE and LE.

Corinna

	* gdb.base/call-rt-st.exp: Fix typos.

Index: gdb.base/call-rt-st.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/call-rt-st.exp,v
retrieving revision 1.15
diff -u -p -r1.15 call-rt-st.exp
--- gdb.base/call-rt-st.exp	6 Jan 2004 19:05:14 -0000	1.15
+++ gdb.base/call-rt-st.exp	1 Sep 2004 14:05:37 -0000
 <at>  <at>  -187,13 +187,13  <at>  <at>  if {![gdb_skip_float_test "print print_t
             ".*Contents of two_floats_t:\[ \r\n\]+-2\\.345000\[ \t]+1\\.000000\[ \r\n\]+.\[0-9\]+ = \\{float1
= -2\\.34500003, float2 = 1\\}"
 }

-if ![gdb_skip_stdio_test "print print_bit_flags_char(*flags)"] {
-    print_struct_call "print_bit_flags_char(*flags)" \
+if ![gdb_skip_stdio_test "print print_bit_flags_char(*cflags)"] {
+    print_struct_call "print_bit_flags_char(*cflags)" \
             ".*alpha\[ \r\n\]+gamma\[ \r\n\]+epsilon\[ \r\n\]+.\[0-9\]+ = \\{alpha = 1 '\\\\001', beta = 0
'\\\\0', gamma = 1 '\\\\001', delta = 0 '\\\\0', epsilon = 1 '\\\\001', omega = 0 '\\\\0'\\}"
 }

-if ![gdb_skip_stdio_test "print print_bit_flags_short(*flags)"] {

[commit] Simplify inside_main_func

Hello,

This re-implements inside_main_func, replacing the old pc-in-range code 
with the simpler frame->entry-point == main->entry-point test.

tested on PPC/NetBSD and i386 GNU/Linux.

committed,
Andrew

2004-08-31  Andrew Cagney  <cagney <at> gnu.org>

	* frame.c: Include "objfiles.h".
	(inside_main_func): New function.
	(get_prev_frame): Use new inside_main_func.
	* Makefile.in (frame.o): Update dependencies.
	* defs.h (inside_main_func): Delete declaration.
	* blockframe.c (inside_main_func): Delete function.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.611
diff -p -u -r1.611 Makefile.in
--- Makefile.in	22 Aug 2004 19:03:41 -0000	1.611
+++ Makefile.in	1 Sep 2004 14:09:03 -0000
 <at>  <at>  -1885,7 +1885,7  <at>  <at>  frame.o: frame.c $(defs_h) $(frame_h) $(
 	$(regcache_h) $(gdb_assert_h) $(gdb_string_h) $(user_regs_h) \
 	$(gdb_obstack_h) $(dummy_frame_h) $(sentinel_frame_h) $(gdbcore_h) \