* Re: [PRELIMINARY]: Patch to add bfd support for IBM s390
[not found] <C1256946.00620C31.00@d12mta09.de.ibm.com>
@ 2000-08-25 11:02 ` Michael Snyder
0 siblings, 0 replies; 3+ messages in thread
From: Michael Snyder @ 2000-08-25 11:02 UTC (permalink / raw)
To: DJBARROW; +Cc: gdb-patches, schwidefsky
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 20165 bytes --]
DJBARROW@de.ibm.com wrote:
>
> Sure thing I'm going back home till Thursday so apologies for the lack of
> correspondance,
> Is 5.0 adequete or should I move to something newer.
If you can, it would be great if you would check out the
up-to-the-minute sources from sourceware.cygnus.com
and submit diffs against those.
> D.J. Barrow Linux for S/390 kernel developer
> eMail: djbarrow@de.ibm.com,barrow_dj@yahoo.com
> Phone: +49-(0)7031-16-2583
> IBM Germany Lab, Schönaicherstr. 220, 71032 Böblingen
>
> Michael Snyder <msnyder@redhat.com> on 25.08.2000 19:35:34
>
> Please respond to Michael Snyder <msnyder@redhat.com>
>
> To: Denis Joseph Barrow/Germany/Contr/IBM@IBMDE
> cc: gdb-patches@sourceware.cygnus.com, Martin
> Schwidefsky/Germany/IBM@IBMDE
> Subject: Re: [PRELIMINARY]: Patch to add bfd support for IBM s390
>
> ---------------------------------------------------------------
>
> DJBARROW@de.ibm.com wrote:
> >
> > Sorry I was referring to hardware watchpoints when making this comment.
> >
> > The breakpoint.c kludge I did as far as I remember is probably unwanted,
> I
> > just found that the
> > hardware breakpoints in 4-18 were in absolutely terrible shape staying in
> > when not wanted &
> > disappearing for no reason, has this code improved ?, my clueless kludge
> > improved the situation a tiny
> > bit in the test cases I was playing with.
> > I haven't had a chance to see whether the 5.0 code has improved
> > substantially in my opinion
> > this code needs a lot of attention by someone who knows it, if this code
> > has improved recently
> > please leave this out.
>
> How about if we remove it from your base port submission,
> and revisit it if necessary after?
From taylor@cygnus.com Fri Aug 25 11:34:00 2000
From: David Taylor <taylor@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA]: search_symbols(in symtab.c) -- fix off by one error
Date: Fri, 25 Aug 2000 11:34:00 -0000
Message-id: <200008251833.OAA05124@texas.cygnus.com>
X-SW-Source: 2000-08/msg00321.html
Content-length: 952
From: Elena Zannoni <ezannoni@cygnus.com>
Date: Fri, 25 Aug 2000 11:56:20 -0400 (EDT)
Yes, true. Approved. Now, though, there is another similar thing in
symtab.c:symtab_symbol_info(). This function also defines an array and
uses LABEL_NAMESPACE to access its elements. But it subtracts 1, so
this is in sync:
Thanks.
symtab_symbol_info (regexp, kind, from_tty)
char *regexp;
namespace_enum kind;
int from_tty;
{
static char *classnames[]
=
{"variable", "function", "type", "method"};
[....]
printf_filtered (regexp
? "All %ss matching regular expression \"%s\":\n"
: "All defined %ss:\n",
classnames[(int) (kind - LABEL_NAMESPACE - 1)], regexp);
[....]
I wonder why LABEL_NAMESPACE was used at all.
Can you fix this above occurrence as well, so it is all consistent?
Done. I'll be committing it later today.
Thanks
Elena
David
From taylor@cygnus.com Fri Aug 25 14:07:00 2000
From: David Taylor <taylor@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] symtab.c -- fix off by one bugs
Date: Fri, 25 Aug 2000 14:07:00 -0000
Message-id: <200008252106.RAA05195@texas.cygnus.com>
X-SW-Source: 2000-08/msg00322.html
Content-length: 1873
The following patch has been applied to symtab.c:
Fri Aug 25 12:11:21 2000 David Taylor <taylor@texas.cygnus.com>
* symtab.c (search_symbols): Fix off by one error in index for
initializing variables ourtype, ourtype2, ourtype3, and ourtype4.
(symtab_symbol_info): fix similar off by one error.
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.12
retrieving revision 1.13
diff -c -r1.12 -r1.13
*** symtab.c 2000/08/11 01:02:35 1.12
--- symtab.c 2000/08/25 20:51:19 1.13
***************
*** 3573,3582 ****
if (kind < LABEL_NAMESPACE)
error ("must search on specific namespace");
! ourtype = types[(int) (kind - LABEL_NAMESPACE)];
! ourtype2 = types2[(int) (kind - LABEL_NAMESPACE)];
! ourtype3 = types3[(int) (kind - LABEL_NAMESPACE)];
! ourtype4 = types4[(int) (kind - LABEL_NAMESPACE)];
sr = *matches = NULL;
tail = NULL;
--- 3573,3582 ----
if (kind < LABEL_NAMESPACE)
error ("must search on specific namespace");
! ourtype = types[(int) (kind - VARIABLES_NAMESPACE)];
! ourtype2 = types2[(int) (kind - VARIABLES_NAMESPACE)];
! ourtype3 = types3[(int) (kind - VARIABLES_NAMESPACE)];
! ourtype4 = types4[(int) (kind - VARIABLES_NAMESPACE)];
sr = *matches = NULL;
tail = NULL;
***************
*** 3903,3909 ****
printf_filtered (regexp
? "All %ss matching regular expression \"%s\":\n"
: "All defined %ss:\n",
! classnames[(int) (kind - LABEL_NAMESPACE - 1)], regexp);
for (p = symbols; p != NULL; p = p->next)
{
--- 3903,3909 ----
printf_filtered (regexp
? "All %ss matching regular expression \"%s\":\n"
: "All defined %ss:\n",
! classnames[(int) (kind - VARIABLES_NAMESPACE)], regexp);
for (p = symbols; p != NULL; p = p->next)
{
From taylor@cygnus.com Fri Aug 25 14:13:00 2000
From: David Taylor <taylor@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] TARGET_ADDR_BIT
Date: Fri, 25 Aug 2000 14:13:00 -0000
Message-id: <200008252113.RAA05208@texas.cygnus.com>
X-SW-Source: 2000-08/msg00323.html
Content-length: 5793
The following patch has been applied:
[NOTE: I'm not including the diffs for gdbarch.c and gdbarch.h -- they
can be generated from gdbarch.sh]
Fri Aug 25 12:03:15 2000 David Taylor <taylor@texas.cygnus.com>
* gdbarch.sh (TARGET_ADDR_BIT): New macro for the number
of bits in gdb's representation of a target address.
* gdbarch.c, gdbarch.h: Regenerated.
* gdbtypes.c (build_gdbtypes): Use TARGET_ADDR_BIT instead of
TARGET_PTR_BIT when initializing builtin_type_CORE_ADDR.
* printcmd.c (print_address_numeric): Use TARGET_ADDR_BIT instead
of TARGET_PTR_BIT, because we're printing an address, not a pointer.
Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.40
retrieving revision 1.41
diff -c -r1.40 -r1.41
*** gdbarch.sh 2000/08/11 03:19:22 1.40
--- gdbarch.sh 2000/08/25 20:51:19 1.41
***************
*** 319,326 ****
v::TARGET_DOUBLE_BIT:int:double_bit::::8 * sizeof (double):8*TARGET_CHAR_BIT::0
# Number of bits in a long double for the target machine.
v::TARGET_LONG_DOUBLE_BIT:int:long_double_bit::::8 * sizeof (long double):2*TARGET_DOUBLE_BIT::0
! # Number of bits in a pointer for the target machine
v::TARGET_PTR_BIT:int:ptr_bit::::8 * sizeof (void*):TARGET_INT_BIT::0
# Number of bits in a BFD_VMA for the target object file format.
v::TARGET_BFD_VMA_BIT:int:bfd_vma_bit::::8 * sizeof (void*):TARGET_ARCHITECTURE->bits_per_address::0
#
--- 319,336 ----
v::TARGET_DOUBLE_BIT:int:double_bit::::8 * sizeof (double):8*TARGET_CHAR_BIT::0
# Number of bits in a long double for the target machine.
v::TARGET_LONG_DOUBLE_BIT:int:long_double_bit::::8 * sizeof (long double):2*TARGET_DOUBLE_BIT::0
! # For most targets, a pointer on the target and its representation as an
! # address in GDB have the same size and "look the same". For such a
! # target, you need only set TARGET_PTR_BIT / ptr_bit and TARGET_ADDR_BIT
! # / addr_bit will be set from it.
! #
! # If TARGET_PTR_BIT and TARGET_ADDR_BIT are different, you'll probably
! # also need to set POINTER_TO_ADDRESS and ADDRESS_TO_POINTER as well.
! #
! # ptr_bit is the size of a pointer on the target
v::TARGET_PTR_BIT:int:ptr_bit::::8 * sizeof (void*):TARGET_INT_BIT::0
+ # addr_bit is the size of a target address as represented in gdb
+ v::TARGET_ADDR_BIT:int:addr_bit::::8 * sizeof (void*):0:TARGET_PTR_BIT:
# Number of bits in a BFD_VMA for the target object file format.
v::TARGET_BFD_VMA_BIT:int:bfd_vma_bit::::8 * sizeof (void*):TARGET_ARCHITECTURE->bits_per_address::0
#
***************
*** 515,527 ****
/* This file was created with the aid of \`\`gdbarch.sh''.
! The bourn shell script \`\`gdbarch.sh'' creates the files
\`\`new-gdbarch.c'' and \`\`new-gdbarch.h and then compares them
against the existing \`\`gdbarch.[hc]''. Any differences found
being reported.
If editing this file, please also run gdbarch.sh and merge any
! changes into that script. Conversely, when makeing sweeping changes
to this file, modifying gdbarch.sh and using its output may prove
easier. */
--- 525,537 ----
/* This file was created with the aid of \`\`gdbarch.sh''.
! The Bourne shell script \`\`gdbarch.sh'' creates the files
\`\`new-gdbarch.c'' and \`\`new-gdbarch.h and then compares them
against the existing \`\`gdbarch.[hc]''. Any differences found
being reported.
If editing this file, please also run gdbarch.sh and merge any
! changes into that script. Conversely, when making sweeping changes
to this file, modifying gdbarch.sh and using its output may prove
easier. */
Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.12
retrieving revision 1.13
diff -c -r1.12 -r1.13
*** gdbtypes.c 2000/07/30 01:48:25 1.12
--- gdbtypes.c 2000/08/25 20:51:19 1.13
***************
*** 2929,2935 ****
though the two can be different (cf d10v) */
builtin_type_ptr = make_pointer_type (builtin_type_void, NULL);
builtin_type_CORE_ADDR =
! init_type (TYPE_CODE_INT, TARGET_PTR_BIT / 8,
TYPE_FLAG_UNSIGNED,
"__CORE_ADDR", (struct objfile *) NULL);
builtin_type_bfd_vma =
--- 2929,2935 ----
though the two can be different (cf d10v) */
builtin_type_ptr = make_pointer_type (builtin_type_void, NULL);
builtin_type_CORE_ADDR =
! init_type (TYPE_CODE_INT, TARGET_ADDR_BIT / 8,
TYPE_FLAG_UNSIGNED,
"__CORE_ADDR", (struct objfile *) NULL);
builtin_type_bfd_vma =
Index: printcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/printcmd.c,v
retrieving revision 1.12
retrieving revision 1.13
diff -c -r1.12 -r1.13
*** printcmd.c 2000/07/30 01:48:26 1.12
--- printcmd.c 2000/08/25 20:51:19 1.13
***************
*** 726,734 ****
kept in the least significant bits of ADDR - the upper bits were
either zero or sign extended. Should ADDRESS_TO_POINTER() or
some ADDRESS_TO_PRINTABLE() be used to do the conversion? */
! int ptr_bit = TARGET_PTR_BIT;
! if (ptr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
! addr &= ((CORE_ADDR) 1 << ptr_bit) - 1;
print_longest (stream, 'x', use_local, (ULONGEST) addr);
}
--- 726,734 ----
kept in the least significant bits of ADDR - the upper bits were
either zero or sign extended. Should ADDRESS_TO_POINTER() or
some ADDRESS_TO_PRINTABLE() be used to do the conversion? */
! int addr_bit = TARGET_ADDR_BIT;
! if (addr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
! addr &= ((CORE_ADDR) 1 << addr_bit) - 1;
print_longest (stream, 'x', use_local, (ULONGEST) addr);
}
From taylor@cygnus.com Fri Aug 25 14:17:00 2000
From: David Taylor <taylor@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] register_changed
Date: Fri, 25 Aug 2000 14:17:00 -0000
Message-id: <200008252116.RAA05221@texas.cygnus.com>
X-SW-Source: 2000-08/msg00324.html
Content-length: 1338
The following patch has been applied:
Fri Aug 25 16:57:05 2000 David Taylor <taylor@texas.cygnus.com>
* regcache.c (register_changed): New function.
* value.h: Declare it.
Index: regcache.c
===================================================================
RCS file: /cvs/src/src/gdb/regcache.c,v
retrieving revision 1.8
retrieving revision 1.9
diff -c -r1.8 -r1.9
*** regcache.c 2000/08/11 19:09:55 1.8
--- regcache.c 2000/08/25 21:03:00 1.9
***************
*** 68,73 ****
--- 68,82 ----
return register_valid[regnum];
}
+ /* REGISTER_CHANGED
+
+ invalidate a single register REGNUM in the cache */
+ void
+ register_changed (int regnum)
+ {
+ register_valid[regnum] = 0;
+ }
+
/* FIND_SAVED_REGISTER ()
Return the address in which frame FRAME's value of register REGNUM
Index: value.h
===================================================================
RCS file: /cvs/src/src/gdb/value.h,v
retrieving revision 1.8
retrieving revision 1.9
diff -c -r1.8 -r1.9
*** value.h 2000/08/16 08:03:43 1.8
--- value.h 2000/08/25 21:03:00 1.9
***************
*** 490,495 ****
--- 490,497 ----
extern int register_cached (int regno);
+ extern void register_changed (int regnum);
+
extern void get_saved_register (char *raw_buffer, int *optimized,
CORE_ADDR * addrp,
struct frame_info *frame,
From ezannoni@cygnus.com Fri Aug 25 18:42:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sources.redhat.com
Cc: dave@hiauly1.hia.nrc.ca
Subject: [PATCH] Fix ANOFFSET problems
Date: Fri, 25 Aug 2000 18:42:00 -0000
Message-id: <14759.8317.764597.718666@kwikemart.cygnus.com>
X-SW-Source: 2000-08/msg00325.html
Content-length: 6814
Dave, please try these fixes.
Sorry about that.
Will commit tomorrow.
Elena
2000-08-25 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
* pa64solib.c (pa64_solib_load_symbols): Don't use ANOFFSET as an
lvalue.
* xcoffread.c (xcoff_symfile_offsets): Ditto
* somsolib.c (som_solib_section_offsets): Ditto.
* somread.c (som_symfile_offsets): Ditto.
* rs6000-nat.c (vmap_symtab): Ditto.
* remote-vx.c (vx_add_symbols): Ditto.
* remote-os9k.c (rombug_wait): Ditto.
Index: pa64solib.c
===================================================================
RCS file: /cvs/src/src/gdb/pa64solib.c,v
retrieving revision 1.6
diff -c -u -p -r1.6 pa64solib.c
--- pa64solib.c 2000/08/09 20:09:01 1.6
+++ pa64solib.c 2000/08/26 01:25:07
@@ -319,9 +319,9 @@ pa64_solib_load_symbols (struct so_list
return;
}
- ANOFFSET (so->objfile->section_offsets, SECT_OFF_TEXT (so->objfile))
+ (so->objfile->section_offsets)->offsets[SECT_OFF_TEXT (so->objfile)]
= so->pa64_solib_desc.text_base;
- ANOFFSET (so->objfile->section_offsets, SECT_OFF_DATA (so->objfile))
+ (so->objfile->section_offsets)->offsets[SECT_OFF_DATA (so->objfile)]
= so->pa64_solib_desc.data_base;
/* Relocate all the sections based on where they got loaded. */
Index: remote-os9k.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-os9k.c,v
retrieving revision 1.4
diff -c -u -p -r1.4 remote-os9k.c
--- remote-os9k.c 2000/07/30 01:48:26 1.4
+++ remote-os9k.c 2000/08/26 01:25:07
@@ -493,8 +493,8 @@ rombug_wait (int pid, struct target_wait
new_symfile_objfile (obj_sec->objfile, 1, 0);
offs = (struct section_offsets *) alloca (SIZEOF_SECTION_OFFSETS);
memcpy (offs, symfile_objfile->section_offsets, SIZEOF_SECTION_OFFSETS);
- ANOFFSET (offs, SECT_OFF_DATA (symfile_objfile)) = addr;
- ANOFFSET (offs, SECT_OFF_BSS (symfile_objfile)) = addr;
+ offs->offsets[SECT_OFF_DATA (symfile_objfile)] = addr;
+ offs->offsets[SECT_OFF_BSS (symfile_objfile)] = addr;
objfile_relocate (symfile_objfile, offs);
}
Index: remote-vx.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-vx.c,v
retrieving revision 1.6
diff -c -u -p -r1.6 remote-vx.c
--- remote-vx.c 2000/08/02 14:52:10 1.6
+++ remote-vx.c 2000/08/26 01:25:08
@@ -685,9 +685,9 @@ vx_add_symbols (char *name, int from_tty
bfd_map_over_sections (objfile->obfd, find_sect, &ss);
/* Both COFF and b.out frontends use these SECT_OFF_* values. */
- ANOFFSET (offs, SECT_OFF_TEXT (objfile)) = text_addr - ss.text_start;
- ANOFFSET (offs, SECT_OFF_DATA (objfile)) = data_addr - ss.data_start;
- ANOFFSET (offs, SECT_OFF_BSS (objfile)) = bss_addr - ss.bss_start;
+ offs->offsets[SECT_OFF_TEXT (objfile)] = text_addr - ss.text_start;
+ offs->offsets[SECT_OFF_DATA (objfile)] = data_addr - ss.data_start;
+ offs->offsets[SECT_OFF_BSS (objfile)] = bss_addr - ss.bss_start;
objfile_relocate (objfile, offs);
}
Index: rs6000-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-nat.c,v
retrieving revision 1.8
diff -c -u -p -r1.8 rs6000-nat.c
--- rs6000-nat.c 2000/08/11 01:30:11 1.8
+++ rs6000-nat.c 2000/08/26 01:25:08
@@ -609,13 +609,13 @@ vmap_symtab (struct vmap *vp)
new_offsets = (struct section_offsets *) alloca (SIZEOF_SECTION_OFFSETS);
for (i = 0; i < objfile->num_sections; ++i)
- ANOFFSET (new_offsets, i) = ANOFFSET (objfile->section_offsets, i);
+ new_offsets->offsets[i] = ANOFFSET (objfile->section_offsets, i);
/* The symbols in the object file are linked to the VMA of the section,
relocate them VMA relative. */
- ANOFFSET (new_offsets, SECT_OFF_TEXT (objfile)) = vp->tstart - vp->tvma;
- ANOFFSET (new_offsets, SECT_OFF_DATA (objfile)) = vp->dstart - vp->dvma;
- ANOFFSET (new_offsets, SECT_OFF_BSS (objfile)) = vp->dstart - vp->dvma;
+ new_offsets->offsets[SECT_OFF_TEXT (objfile)] = vp->tstart - vp->tvma;
+ new_offsets->offsets[SECT_OFF_DATA (objfile)] = vp->dstart - vp->dvma;
+ new_offsets->offsets[SECT_OFF_BSS (objfile)] = vp->dstart - vp->dvma;
objfile_relocate (objfile, new_offsets);
}
Index: somread.c
===================================================================
RCS file: /cvs/src/src/gdb/somread.c,v
retrieving revision 1.6
diff -c -u -p -r1.6 somread.c
--- somread.c 2000/07/30 01:48:27 1.6
+++ somread.c 2000/08/26 01:25:08
@@ -477,7 +477,7 @@ som_symfile_offsets (struct objfile *obj
text_addr = addrs->other[i].addr;
for (i = 0; i < SECT_OFF_MAX; i++)
- ANOFFSET (objfile->section_offsets, i) = text_addr;
+ (objfile->section_offsets)->offsets[i] = text_addr;
}
}
Index: somsolib.c
===================================================================
RCS file: /cvs/src/src/gdb/somsolib.c,v
retrieving revision 1.5
diff -c -u -p -r1.5 somsolib.c
--- somsolib.c 2000/07/30 01:48:27 1.5
+++ somsolib.c 2000/08/26 01:25:09
@@ -1378,10 +1378,10 @@ som_solib_section_offsets (struct objfil
asection *private_section;
/* The text offset is easy. */
- ANOFFSET (offsets, SECT_OFF_TEXT (objfile))
+ offsets->offsets[SECT_OFF_TEXT (objfile)]
= (so_list->som_solib.text_addr
- so_list->som_solib.text_link_addr);
- ANOFFSET (offsets, SECT_OFF_RODATA (objfile))
+ offsets->offsets[SECT_OFF_RODATA (objfile)]
= ANOFFSET (offsets, SECT_OFF_TEXT (objfile));
/* We should look at presumed_dp in the SOM header, but
@@ -1391,13 +1391,13 @@ som_solib_section_offsets (struct objfil
if (!private_section)
{
warning ("Unable to find $PRIVATE$ in shared library!");
- ANOFFSET (offsets, SECT_OFF_DATA (objfile)) = 0;
- ANOFFSET (offsets, SECT_OFF_BSS (objfile)) = 0;
+ offsets->offsets[SECT_OFF_DATA (objfile)] = 0;
+ offsets->offsets[SECT_OFF_BSS (objfile)] = 0;
return 1;
}
- ANOFFSET (offsets, SECT_OFF_DATA (objfile))
+ offsets->offsets[SECT_OFF_DATA (objfile)]
= (so_list->som_solib.data_start - private_section->vma);
- ANOFFSET (offsets, SECT_OFF_BSS (objfile))
+ offsets->offsets[SECT_OFF_BSS (objfile)]
= ANOFFSET (offsets, SECT_OFF_DATA (objfile));
return 1;
}
Index: xcoffread.c
===================================================================
RCS file: /cvs/src/src/gdb/xcoffread.c,v
retrieving revision 1.8
diff -c -u -p -r1.8 xcoffread.c
--- xcoffread.c 2000/08/07 15:16:15 1.8
+++ xcoffread.c 2000/08/26 01:25:09
@@ -2744,7 +2744,7 @@ xcoff_symfile_offsets (struct objfile *o
sensibly), so just ignore the addr parameter and use 0.
rs6000-nat.c will set the correct section offsets via
objfile_relocate. */
- ANOFFSET (objfile->section_offsets, i) = 0;
+ (objfile->section_offsets)->offsets[i] = 0;
}
}
^ permalink raw reply [flat|nested] 3+ messages in thread