rs6000-tdep

rs6000-tdep

[Steven Johnson]

To anyone that knows,

Is rs6000-tdep.c supposed to be broken in the current CVS tree? (ie, is it a
multi-arch work in progress? Or should i investigate why i can't build
GDB/Insight deeper?)

Steven Johnson

Re: rs6000-tdep

[Andrew Cagney]

Steven Johnson wrote:
> 
> To anyone that knows,
> 
> Is rs6000-tdep.c supposed to be broken in the current CVS tree? (ie, is it a
> multi-arch work in progress? Or should i investigate why i can't build
> GDB/Insight deeper?)

FYI,

You should always expect GDB to build.  Could I suggest posting a few
more details on the build failure?

	Andrew

Re: rs6000-tdep

[Steven Johnson]

Andrew Cagney wrote:
> 
> You should always expect GDB to build.  Could I suggest posting a few
> more details on the build failure?
> 
>         Andrew

No Problem,

I configured and built from a copy of the CVS tree with the following
script. (Known to have worked with just prior to 5.0). 

# Create Build directory, getting rid of any previous build
rm -rf powerpc-gdb-build
mkdir  powerpc-gdb-build

cd     powerpc-gdb-build
../src/configure --target=powerpc-eabi         \
                 --program-prefix=insight-ppc- \
                 --prefix=/opt/powerpc-gdb
make all install         

And i get the following:

<Lots of configure messages and then lots of compilation and then:...>

gcc -c -g -O2    -I. -I../../src/gdb -I../../src/gdb/config
-DHAVE_CONFIG_H -I../../src/gdb/../include/opcode
-I../../src/gdb/../readline/.. -I../bfd -I../../src/gdb/../bfd 
-I../../src/gdb/../include -I../intl -I../../src/gdb/../intl -DGDBTK
-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses
-Wpointer-arith -Wuninitialized  ../../src/gdb/rs6000-tdep.c
../../src/gdb/rs6000-tdep.c:60: warning: `DEFAULT_LR_SAVE' redefined
tm.h:31: warning: this is the location of the previous definition
In file included from /usr/include/string.h:346,
                 from ../../src/gdb/../include/obstack.h:145,
                 from ../../src/gdb/symtab.h:27,
                 from ../../src/gdb/value.h:240,
                 from ../../src/gdb/breakpoint.h:25,
                 from ../../src/gdb/inferior.h:26,
                 from ../../src/gdb/rs6000-tdep.c:24:
/usr/include/bits/string2.h: In function `__strcpy_small':
/usr/include/bits/string2.h:419: warning: pointer of type `void *' used
in arithmetic
/usr/include/bits/string2.h:427: warning: pointer of type `void *' used
in arithmetic
/usr/include/bits/string2.h:432: warning: pointer of type `void *' used
in arithmetic
/usr/include/bits/string2.h:437: warning: pointer of type `void *' used
in arithmetic
/usr/include/bits/string2.h:439: warning: pointer of type `void *' used
in arithmetic
/usr/include/bits/string2.h:444: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c: In function `skip_prologue':
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:406: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:395: warning: `last_prologue_pc' might be
used uninitialized in this function
../../src/gdb/rs6000-tdep.c: At top level:
../../src/gdb/rs6000-tdep.c:689: conflicting types for
`rs6000_pop_frame'
tm.h:57: previous declaration of `rs6000_pop_frame'
../../src/gdb/rs6000-tdep.c: In function `rs6000_push_arguments':
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:869: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c:885: warning: pointer of type `void *' used
in arithmetic
../../src/gdb/rs6000-tdep.c: At top level:
../../src/gdb/rs6000-tdep.c:994: warning: static declaration for
`ppc_push_return_address' follows non-static
make[1]: *** [rs6000-tdep.o] Error 1
make[1]: Leaving directory
`/home/steven/dev/tools/gdb/powerpc-gdb-build/gdb'
make: *** [all-gdb] Error 2

It looks to me like some conflict between tm.h and rs6000-tdep.c. I'm
looking at this problem now, but if you see anything obvious i'd like to
hear it.

Thanks,
Steven Johnson
 PS. Im also going to look at getting rid of that really ugly 'pointer
of type void*' warning also.

Re: rs6000-tdep

[Andrew Cagney]

Steven Johnson wrote:
> 
> Andrew Cagney wrote:
> >
> > You should always expect GDB to build.  Could I suggest posting a few
> > more details on the build failure?
> >
> >         Andrew
> 
> No Problem,
> 
> I configured and built from a copy of the CVS tree with the following
> script. (Known to have worked with just prior to 5.0).
> 
> # Create Build directory, getting rid of any previous build
> rm -rf powerpc-gdb-build
> mkdir  powerpc-gdb-build
> 
> cd     powerpc-gdb-build
> ../src/configure --target=powerpc-eabi         \
>                  --program-prefix=insight-ppc- \
>                  --prefix=/opt/powerpc-gdb
> make all install
> 
> And i get the following:

Yes, that should build.

> make[1]: *** [rs6000-tdep.o] Error 1
> make[1]: Leaving directory
> `/home/steven/dev/tools/gdb/powerpc-gdb-build/gdb'
> make: *** [all-gdb] Error 2
> 
> It looks to me like some conflict between tm.h and rs6000-tdep.c. I'm
> looking at this problem now, but if you see anything obvious i'd like to
> hear it.
> 
> Thanks,
> Steven Johnson
>  PS. Im also going to look at getting rid of that really ugly 'pointer
> of type void*' warning also.

Hmm, configuring with --disable-build-warnings or
--enable-build-warnings= might be easiest - I suspect the problem might
be in th memcpy() macro :-(

	Andrew

Re: rs6000-tdep

[Mark Kettenis]

   Date: Fri, 14 Jul 2000 22:34:19 +1000
   From: Steven Johnson <sbjohnson@ozemail.com.au>

    PS. Im also going to look at getting rid of that really ugly 'pointer
   of type void*' warning also.

Caused by a bug in gcc.  (The use of `void *' in pointer arithmetic in
the glibc headers is marked with __extension__, but gcc nevertheless
complains about it).  You can avoid it by not passing -Wpointer-airth
to the compiler.  How is left as en excercise to the reader :-).

Mark

Re: rs6000-tdep

[Steven Johnson]

Andrew,

I fixed that problem, by fixing the definition of rs6000_pop_frame in
tm-ppc-eabi.h. BUT,
then it borke further on in the compile because NUM_REGS was not defined
anywhere for PowerPC. Which is also attempted to fix, and then it broke
again in ppc-bdm.c, because MQ_REGNUM was undeclared. It seems GDB in
this 
regard (at least for me) is chronically busted. Each problem is quite
significant and i can't see how it could have ever compiled anywhere
with these
problems. I think, maybe, my CVS repository is corrupted. Im going to
get the latest snapshot and try and compile it. I will let you know what
I find.

On another note, there used to be an extensive list of register names
defined for varients of the PowerPC architecture, for example all of the
SPR registers specific to the MPC860, etc. They seem to have disappeard
in the Multi-arch process. Is this possible? If so, where do I find
information on putting them back, without breaking the Multiarch stuff? 

Also, the pointer warning is in the GCC library header on my linux box,
so I will ignore it for now. (As has just been pointed out :)

regards,
Steven Johnson

Re: rs6000-tdep

[Nick Duffek]

On 14-Jul-2000, Steven Johnson wrote:

>Each problem is quite
>significant and i can't see how it could have ever compiled anywhere
>with these problems.

Yup, my AIX multi-arch changes a few weeks ago broke powerpc-eabi.  Could
you try the appended patch?

>On another note, there used to be an extensive list of register names
>defined for varients of the PowerPC architecture, for example all of the
>SPR registers specific to the MPC860, etc.

They're still in rs6000-tdep.c.  I tried to make them available via the
generic multi-arch "set architecture" command, but I haven't been able to
test them on various PowerPC variants, so it's possible that there's some
breakage.

Kevin, is it okay to commit this powerpc-eabi patch?

Nick Duffek
nsd@redhat.com

[patch follows]

Index: ppcbug-rom.c
===================================================================
RCS file: /cvs/src/src/gdb/ppcbug-rom.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 ppcbug-rom.c
--- ppcbug-rom.c	1999/09/08 23:59:24	1.1.1.3
+++ ppcbug-rom.c	2000/07/07 17:08:10
@@ -104,7 +104,7 @@
  * registers either. So, typing "info reg sp" becomes an "A7".
  */
 
-static char *ppcbug_regnames[NUM_REGS] =
+static char *ppcbug_regnames[] =
 {
   "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7",
   "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15",
Index: gdb/rs6000-tdep.c
===================================================================
diff -up gdb/rs6000-tdep.c gdb/rs6000-tdep.c
--- gdb/rs6000-tdep.c	Tue Jun 20 21:19:07 2000
+++ gdb/rs6000-tdep.c	Tue Jun 20 21:17:27 2000
@@ -56,9 +56,6 @@
 #define SIG_FRAME_LR_OFFSET 108
 #define SIG_FRAME_FP_OFFSET 284
 
-/* Default offset from SP where the LR is stored */
-#define	DEFAULT_LR_SAVE 8
-
 /* To be used by skip_prologue. */
 
 struct rs6000_framedata
@@ -2048,7 +2045,7 @@ rs6000_gdbarch_init (struct gdbarch_info
   set_gdbarch_call_dummy_breakpoint_offset_p (gdbarch, 1);
   set_gdbarch_call_dummy_breakpoint_offset (gdbarch, 0);
   set_gdbarch_call_dummy_start_offset (gdbarch, 0);
-  set_gdbarch_pc_in_call_dummy (gdbarch, rs6000_pc_in_call_dummy);
+  set_gdbarch_pc_in_call_dummy (gdbarch, generic_pc_in_call_dummy);
   set_gdbarch_call_dummy_p (gdbarch, 1);
   set_gdbarch_call_dummy_stack_adjust_p (gdbarch, 0);
   set_gdbarch_get_saved_register (gdbarch, generic_get_saved_register);
Index: gdb/config/rs6000/tm-rs6000.h
===================================================================
diff -up gdb/config/rs6000/tm-rs6000.h gdb/config/rs6000/tm-rs6000.h
--- gdb/config/rs6000/tm-rs6000.h	Tue Jun 20 21:19:13 2000
+++ gdb/config/rs6000/tm-rs6000.h	Tue Jun 20 21:18:24 2000
@@ -94,6 +94,9 @@ extern void aix_process_linenos (void);
 	      prev->next ? FRAME_SAVED_PC (prev->next) : read_pc ());
 #define INIT_FRAME_PC(fromleaf, prev)	/* nothing */
 
+/* Default offset from SP where the LR is stored */
+#define	DEFAULT_LR_SAVE 8
+
 /* Usually a function pointer's representation is simply the address
    of the function. On the RS/6000 however, a function pointer is
    represented by a pointer to a TOC entry. This TOC entry contains
Index: gdb/config/powerpc/tm-ppc-eabi.h
===================================================================
diff -up gdb/config/powerpc/tm-ppc-eabi.h gdb/config/powerpc/tm-ppc-eabi.h
--- gdb/config/powerpc/tm-ppc-eabi.h	Tue Jun 20 21:19:23 2000
+++ gdb/config/powerpc/tm-ppc-eabi.h	Tue Jun 20 21:17:58 2000
@@ -30,8 +30,6 @@
 #undef	DEFAULT_LR_SAVE
 #define	DEFAULT_LR_SAVE 4	/* eabi saves LR at 4 off of SP */
 
-#define GDB_TARGET_POWERPC
-
 #undef PC_LOAD_SEGMENT
 #undef PROCESS_LINENUMBER_HOOK
 
@@ -42,38 +40,6 @@
 #define ELF_OBJECT_FORMAT 1
 
 #define TARGET_BYTE_ORDER_SELECTABLE_P 1
-
-/* return true if a given `pc' value is in `call dummy' function. */
-/* FIXME: This just checks for the end of the stack, which is broken
-   for things like stepping through gcc nested function stubs.  */
-#undef PC_IN_CALL_DUMMY
-
-/* generic dummy frame stuff */
-
-
-
-/* target-specific dummy_frame stuff */
-
-extern struct frame_info *rs6000_pop_frame (struct frame_info *frame);
-
-extern CORE_ADDR ppc_push_return_address (CORE_ADDR, CORE_ADDR);
-
-#undef PUSH_DUMMY_FRAME
-#define PUSH_DUMMY_FRAME             generic_push_dummy_frame ()
-
-#define PUSH_RETURN_ADDRESS(PC, SP)      ppc_push_return_address (PC, SP)
-
-/* override the standard get_saved_register function with 
-   one that takes account of generic CALL_DUMMY frames */
-#define GET_SAVED_REGISTER(raw_buffer, optimized, addrp, frame, regnum, lval) \
-      generic_get_saved_register (raw_buffer, optimized, addrp, frame, regnum, lval)
-
-#define USE_GENERIC_DUMMY_FRAMES 1
-#define CALL_DUMMY_BREAKPOINT_OFFSET (0)
-#define CALL_DUMMY_LOCATION          AT_ENTRY_POINT
-#define CALL_DUMMY_ADDRESS()         entry_point_address ()
-#undef CALL_DUMMY_START_OFFSET
-#define CALL_DUMMY_START_OFFSET      0
 
 /* The value of symbols of type N_SO and N_FUN maybe null when 
    it shouldn't be. */

Re: rs6000-tdep

[Kevin Buettner]

On Jul 14, 10:53am, Nick Duffek wrote:

> Kevin, is it okay to commit this powerpc-eabi patch?

Yes.

Re: rs6000-tdep

[Nick Duffek]

On 14-Jul-2000, Kevin Buettner wrote:

>On Jul 14, 10:53am, Nick Duffek wrote:
>
>> Kevin, is it okay to commit this powerpc-eabi patch?
>
>Yes.

I've committed it.

Nick

Re: rs6000-tdep - Further Developments

[Steven Johnson]

I updated my tree, after Nick commited his patch. Some Problems went
away, and some remained. By Hacking in the files I was able to get a
compile, but im suspicious about it's operation. Details follow:

dink32-rom.c did not compile. (I had to remove NUM_REGS from the
definition of dink32_regnames)
ppc-bdm.c did not compile. (MQ_REGNUM was not defined, I just deleted
any reference to it as I don't use this target.)

After this, I was able to get a clean build and install.

After installings, I tried to run it.

It starts up, I type:
target remote localhost:2345

to connect to a stub driver program i wrote that is listening on port
2345 i get the response:
localhost:2345: Success.

If my stub driver program is not running i get: 
localhost:2345: No such file or directory.

All of this looks fine, except:
1. My driver program has not actually been connected to, it is still
listening on port 2345 for a connection. (This program works with
earlier versions of GDB fine.)
2. All operations, like trying to read memory, fail, for example:
   (gdb) x 0
   0x0:    Cannot access memory at address 0x0.

I can also tell that no operations have been attempted on my stub driver
program (not surprising since it has not been connected to.)

So while the build has progressed, GDB in CVS is stil profoundly broken
for powerpc eabi. (as far as I have been able to determine).

If anyone has any suggestions as to what I might be doing wrong i'd love
to know.

Steven Johnson

Nick Duffek wrote:
> 
> On 14-Jul-2000, Kevin Buettner wrote:
> 
> >On Jul 14, 10:53am, Nick Duffek wrote:
> >
> >> Kevin, is it okay to commit this powerpc-eabi patch?
> >
> >Yes.
> 
> I've committed it.
> 
> Nick

Re: rs6000-tdep - Further Developments

[Fernando Nasser]

Steven Johnson wrote:
> 
> It starts up, I type:
> target remote localhost:2345
> 
> to connect to a stub driver program i wrote that is listening on port
> 2345 i get the response:
> localhost:2345: Success.
> 
> If my stub driver program is not running i get:
> localhost:2345: No such file or directory.
> 
> All of this looks fine, except:
> 1. My driver program has not actually been connected to, it is still
> listening on port 2345 for a connection. (This program works with
> earlier versions of GDB fine.)

1) Use "set debug remote 2" and see what exactly happen when you issue
   your "target remote ..." command.

2) If this does not give you the indication of what is going wrong,
   use tcpdump to verify what is really going on between gdb and your stub.

BTW, this code is not particular to powerpc and it works everywhere else.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

regcache.c/regcache.h

[Steven Johnson]

Ive grown sick of regcache.c having it's definitions spread across half
a dozen different headers.

Is there any good reason why I shouldn't collate this stuff into a
single header, and call it for arguments sake regcache.h?

In anticipation of the answer being "Sounds good to me" I have already
started this. hoping to have it finished tonight. (If i can remain
conscious)

Steven.

Re: regcache.c/regcache.h

[Steven Johnson]

OK, Ive created the header, propogated it's #include through about 37
files, and am still going. Im going to finish it in about 18 hrs time,
(I know im weak, I must sleep) prepare for patch of this in about 24hrs.

Oh yeah, if there are any really good reasons why I shouldn't be doing
this then just let me say "doh" now.

Steven.

Steven Johnson wrote:
> 
> Ive grown sick of regcache.c having it's definitions spread across half
> a dozen different headers.
> 
> Is there any good reason why I shouldn't collate this stuff into a
> single header, and call it for arguments sake regcache.h?
> 
> In anticipation of the answer being "Sounds good to me" I have already
> started this. hoping to have it finished tonight. (If i can remain
> conscious)
> 
> Steven.