* Re: Patch to let Alpha debuggers debug a remote target over Telnet
2000-04-25 20:20 ` Andrew Cagney
@ 2000-04-26 12:00 ` Guy Harris
0 siblings, 0 replies; 3+ messages in thread
From: Guy Harris @ 2000-04-26 12:00 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Guy Harris, gdb-patches
> (I'm now slightly confused. You have been trying this with the current
> sources?)
"Trying" in what sense?
I made sure that it built, but we've not actually been using anything
built from the current sources as a debugger for our appliances.
From eliz@delorie.com Wed Apr 26 13:16:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kevinb@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] config/djgpp/fnchange.lst change for IA-64
Date: Wed, 26 Apr 2000 13:16:00 -0000
Message-id: <200004262016.QAA24197@indy.delorie.com>
References: <1000426170421.ZM13236@ocotillo.lan>
X-SW-Source: 2000-04/msg00481.html
Content-length: 432
> Date: Wed, 26 Apr 2000 10:04:21 -0700
> From: Kevin Buettner <kevinb@cygnus.com>
>
> I request approval for committing the patch below. This patch was
> requested by Eli Zaretskii. Note that I decided to follow Mark
> Kettenis' advice and mangle the name of ia64-linux-nat.c instead
> of ia64-linux-tdep.c.
>
> * config/djgpp/fnchange.lst (ia64-linux-nat.c): Map to
> ia64linux-nat.c.
Approved (trunk and branch).
Thanks!
From eliz@delorie.com Wed Apr 26 13:18:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: gdb/mi add section documenting proposed syntax changes
Date: Wed, 26 Apr 2000 13:18:00 -0000
Message-id: <200004262018.QAA24210@indy.delorie.com>
References: <3906B478.775F0957@cygnus.com>
X-SW-Source: 2000-04/msg00482.html
Content-length: 519
> Date: Wed, 26 Apr 2000 19:18:48 +1000
> From: Andrew Cagney <ac131313@cygnus.com>
>
> Look ok? branch?
Looks okay as far as the markup goes, except for this:
> + * GDB/MI Draft 2.0 Output Syntax::
Periods is a no-no in a node name (some Info browsers, including
Emacs, get confused by such node names).
Note that there are a few more references to this node name in the
patch; they all need to be changed.
I cannot say anything about the contents, but other than that, I think
it can go into the branch as well.
From msnyder@cygnus.com Wed Apr 26 14:29:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: hook gdbarch into corefiles.
Date: Wed, 26 Apr 2000 14:29:00 -0000
Message-id: <39075FCB.1EBB@cygnus.com>
X-SW-Source: 2000-04/msg00483.html
Content-length: 963
If no one objects, I will check in the following change.
It groks the architecture from a corefile, and passes it
to gdbarch (just like is currently done for an executable
file).
2000-04-26 Michael Snyder <msnyder@cleaver.cygnus.com>
* corelow.c (core_open): call set_gdbarch_from_file so that
gdbarch becomes aware of the architecture encoded in the
corefile.
Index: corelow.c
===================================================================
RCS file: /cvs/src/src/gdb/corelow.c,v
retrieving revision 1.1.1.6
diff -p -r1.1.1.6 corelow.c
*** corelow.c 1999/12/08 02:50:37 1.1.1.6
--- corelow.c 2000/04/26 21:19:11
*************** core_open (filename, from_tty)
*** 318,323 ****
--- 318,325 ----
error ("\"%s\": Can't find sections: %s",
bfd_get_filename (core_bfd), bfd_errmsg (bfd_get_error ()));
+ set_gdbarch_from_file (core_bfd);
+
ontop = !push_target (&core_ops);
discard_cleanups (old_chain);
From kevinb@cygnus.com Wed Apr 26 14:37:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] config/djgpp/fnchange.lst change for IA-64
Date: Wed, 26 Apr 2000 14:37:00 -0000
Message-id: <1000426213706.ZM13736@ocotillo.lan>
References: <1000426170421.ZM13236@ocotillo.lan> <200004262016.QAA24197@indy.delorie.com> <eliz@delorie.com>
X-SW-Source: 2000-04/msg00484.html
Content-length: 748
On Apr 26, 4:16pm, Eli Zaretskii wrote:
> > * config/djgpp/fnchange.lst (ia64-linux-nat.c): Map to
> > ia64linux-nat.c.
>
> Approved (trunk and branch).
Committed - trunk only.
There won't be a conflict on the branch since I haven't added (nor do
I plan to add) ia64-linux-tdep.c to the branch. At the time the branch
was made, the gdb directory was up-to-date for IA-64, but the opcodes
and bfd directories were not. So I'm not going to bother with keeping
the branch up-to-date for IA-64 since it won't build anyway.
The situation on the trunk has recently changed, however. Jim Wilson
has committed the necessary pieces to bfd and opcodes and it is now
possible to build a working gdb for IA-64 out of sourceware. (Hooray!)
Kevin
From msnyder@cygnus.com Wed Apr 26 14:40:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: fix compiler warning in java val_print.
Date: Wed, 26 Apr 2000 14:40:00 -0000
Message-id: <39076237.3F6A@cygnus.com>
X-SW-Source: 2000-04/msg00485.html
Content-length: 815
This (a declaration for a function argument) gets rid of
a gcc -Wall warning in jv-valprint.c:
2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
* jv-valprint.c (java_val_print): add arg declaration,
fix compiler warning.
Index: jv-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/jv-valprint.c,v
retrieving revision 1.1.1.6
diff -p -r1.1.1.6 jv-valprint.c
*** jv-valprint.c 2000/02/02 00:21:08 1.1.1.6
--- jv-valprint.c 2000/04/26 21:19:11
*************** java_val_print (type, valaddr, embedded_
*** 454,459 ****
--- 454,460 ----
deref_ref, recurse, pretty)
struct type *type;
char *valaddr;
+ int embedded_offset;
CORE_ADDR address;
struct ui_file *stream;
int format;
From msnyder@cygnus.com Wed Apr 26 14:44:00 2000
From: msnyder@cygnus.com
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: multi-arch fix for monitor.c
Date: Wed, 26 Apr 2000 14:44:00 -0000
Message-id: <200004262144.OAA05362@seadog.cygnus.com>
X-SW-Source: 2000-04/msg00486.html
Content-length: 1237
2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
* monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE
is not static in the MULTI_ARCH world, so don't use it in a
static array declaration.
Index: monitor.c
===================================================================
RCS file: /cvs/src/src/gdb/monitor.c,v
retrieving revision 1.4
diff -c -r1.4 monitor.c
*** monitor.c 2000/04/04 02:08:52 1.4
--- monitor.c 2000/04/26 21:41:38
***************
*** 1206,1216 ****
int regno;
{
char *name;
! static char zerobuf[MAX_REGISTER_RAW_SIZE] =
! {0};
! char regbuf[MAX_REGISTER_RAW_SIZE * 2 + 1];
int i;
name = current_monitor->regnames[regno];
monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null name)");
--- 1206,1221 ----
int regno;
{
char *name;
! static char *zerobuf;
! char *regbuf;
int i;
+ if (zerobuf == NULL)
+ {
+ zerobuf = alloca (MAX_REGISTER_RAW_SIZE);
+ memset (zerobuf, 0, MAX_REGISTER_RAW_SIZE);
+ }
+ regbuf = alloca (MAX_REGISTER_RAW_SIZE * 2 + 1);
name = current_monitor->regnames[regno];
monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null name)");
From msnyder@cygnus.com Wed Apr 26 15:01:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: multi-arch fix for monitor.c
Date: Wed, 26 Apr 2000 15:01:00 -0000
Message-id: <3907671D.51B3@cygnus.com>
References: <200004262144.OAA05362@seadog.cygnus.com>
X-SW-Source: 2000-04/msg00487.html
Content-length: 1443
Oops, there's a mistake in here -- please disregard,
and I'll resubmit in a few minutes.
msnyder@cygnus.com wrote:
>
> 2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
>
> * monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE
> is not static in the MULTI_ARCH world, so don't use it in a
> static array declaration.
>
> Index: monitor.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/monitor.c,v
> retrieving revision 1.4
> diff -c -r1.4 monitor.c
> *** monitor.c 2000/04/04 02:08:52 1.4
> --- monitor.c 2000/04/26 21:41:38
> ***************
> *** 1206,1216 ****
> int regno;
> {
> char *name;
> ! static char zerobuf[MAX_REGISTER_RAW_SIZE] =
> ! {0};
> ! char regbuf[MAX_REGISTER_RAW_SIZE * 2 + 1];
> int i;
>
> name = current_monitor->regnames[regno];
> monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null name)");
>
> --- 1206,1221 ----
> int regno;
> {
> char *name;
> ! static char *zerobuf;
> ! char *regbuf;
> int i;
>
> + if (zerobuf == NULL)
> + {
> + zerobuf = alloca (MAX_REGISTER_RAW_SIZE);
> + memset (zerobuf, 0, MAX_REGISTER_RAW_SIZE);
> + }
> + regbuf = alloca (MAX_REGISTER_RAW_SIZE * 2 + 1);
> name = current_monitor->regnames[regno];
> monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null name)");
>
From jimb@zwingli.cygnus.com Wed Apr 26 15:17:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] in_prologue() fix
Date: Wed, 26 Apr 2000 15:17:00 -0000
Message-id: <nphfcojymh.fsf@zwingli.cygnus.com>
References: <14598.9829.764888.505476@kwikemart.cygnus.com>
X-SW-Source: 2000-04/msg00488.html
Content-length: 953
> It may be that the real fix is to make ecs->stop_func_start be the
> beginning of the function where the adjusted stop_pc is. However that
> would require several changes to H.I.E. But in any event in_prologue()
> is wrong for this particular case.
My first question is, if HIE can find enough symbolic information to
set ecs->stop_func_{name,start,end}, how come in_prologue can't find
it?
In other words: your explanation implies that HIE has some way to find
the function extent, but happens to be wrong because of
DECR_PC_AFTER_BREAK lossage. But in_prologue knows the correct PC;
why can't it use the same mechanism HIE used earlier to get the right
answer?
Also, aren't there other adverse consequences when
ecs->stop_func_{name,start,end} are wrong? I think the HIE fix is the
right thing. HIE is painful for me too, but otherwise, you'll just
get another CR in a month.
If you've tested the change on SPARC and i386, it's okay with me.
From msnyder@cygnus.com Wed Apr 26 15:57:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: multi-arch fix for monitor.c
Date: Wed, 26 Apr 2000 15:57:00 -0000
Message-id: <3907743C.BDD@cygnus.com>
References: <200004262144.OAA05362@seadog.cygnus.com>
X-SW-Source: 2000-04/msg00489.html
Content-length: 1250
OK, try #2:
2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
* monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE
is not static in the MULTI_ARCH world, so don't use it in a
static array declaration.
Index: monitor.c
===================================================================
RCS file: /cvs/src/src/gdb/monitor.c,v
retrieving revision 1.4
diff -c -r1.4 monitor.c
*** monitor.c 2000/04/04 02:08:52 1.4
--- monitor.c 2000/04/26 21:41:38
***************
*** 1206,1216 ****
int regno;
{
char *name;
! static char zerobuf[MAX_REGISTER_RAW_SIZE] =
! {0};
! char regbuf[MAX_REGISTER_RAW_SIZE * 2 + 1];
int i;
name = current_monitor->regnames[regno];
monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null
name)");
--- 1206,1221 ----
int regno;
{
char *name;
! static char *zerobuf;
! char *regbuf;
int i;
+ if (zerobuf == NULL)
+ {
+ zerobuf = malloc (MAX_REGISTER_RAW_SIZE);
+ memset (zerobuf, 0, MAX_REGISTER_RAW_SIZE);
+ }
+ regbuf = alloca (MAX_REGISTER_RAW_SIZE * 2 + 1);
name = current_monitor->regnames[regno];
monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null
name)");
From ac131313@cygnus.com Wed Apr 26 16:02:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Guy Harris <guy@netapp.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch to let Alpha debuggers debug a remote target over Telnet
Date: Wed, 26 Apr 2000 16:02:00 -0000
Message-id: <39077516.22FB908E@cygnus.com>
References: <200004261858.LAA08141@tooting>
X-SW-Source: 2000-04/msg00490.html
Content-length: 369
Guy Harris wrote:
>
> > (I'm now slightly confused. You have been trying this with the current
> > sources?)
>
> "Trying" in what sense?
>
> I made sure that it built, but we've not actually been using anything
> built from the current sources as a debugger for our appliances.
Sorry, yes. That is what I ment. The current sources build with the
change.
Andrew
From ac131313@cygnus.com Wed Apr 26 16:10:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: multi-arch fix for monitor.c
Date: Wed, 26 Apr 2000 16:10:00 -0000
Message-id: <39077739.62400899@cygnus.com>
References: <200004262144.OAA05362@seadog.cygnus.com> <3907743C.BDD@cygnus.com>
X-SW-Source: 2000-04/msg00491.html
Content-length: 1554
Michael Snyder wrote:
>
> OK, try #2:
>
> 2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
>
> * monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE
> is not static in the MULTI_ARCH world, so don't use it in a
> static array declaration.
I'm not so sure :-( MAX_REGISTER_RAW_SIZE can change and hence the
allocated size of zerobuf could need to change.
What about chaning its only use to write_register (..., 0)?
Andrew
>
> Index: monitor.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/monitor.c,v
> retrieving revision 1.4
> diff -c -r1.4 monitor.c
> *** monitor.c 2000/04/04 02:08:52 1.4
> --- monitor.c 2000/04/26 21:41:38
> ***************
> *** 1206,1216 ****
> int regno;
> {
> char *name;
> ! static char zerobuf[MAX_REGISTER_RAW_SIZE] =
> ! {0};
> ! char regbuf[MAX_REGISTER_RAW_SIZE * 2 + 1];
> int i;
>
> name = current_monitor->regnames[regno];
> monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null
> name)");
>
> --- 1206,1221 ----
> int regno;
> {
> char *name;
> ! static char *zerobuf;
> ! char *regbuf;
> int i;
>
> + if (zerobuf == NULL)
> + {
> + zerobuf = malloc (MAX_REGISTER_RAW_SIZE);
> + memset (zerobuf, 0, MAX_REGISTER_RAW_SIZE);
> + }
> + regbuf = alloca (MAX_REGISTER_RAW_SIZE * 2 + 1);
> name = current_monitor->regnames[regno];
> monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null
> name)");
From fche@cygnus.com Wed Apr 26 16:15:00 2000
From: fche@cygnus.com (Frank Ch. Eigler)
To: gdb-patches@sourceware.cygnus.com
Cc: msnyder@cygnus.com
Subject: Re: [PATCH]: multi-arch fix for monitor.c
Date: Wed, 26 Apr 2000 16:15:00 -0000
Message-id: <o5itx45ujo.fsf@toenail.to.cygnus.com>
References: <200004262144.OAA05362@seadog.cygnus.com> <3907743C.BDD@cygnus.com>
X-SW-Source: 2000-04/msg00492.html
Content-length: 418
msnyder wrote:
> ! static char *zerobuf;
> + if (zerobuf == NULL)
> + zerobuf = malloc (MAX_REGISTER_RAW_SIZE);
Something is still a little suspicious.
If the gdbarch were to change during run time, there is no way to
reallocate space to match the new MAX_REGISTER_RAW_SIZE. That value
is treated a de facto constant.
Is allocating a new zerobuf too at every call too much work?
- FChE
From msnyder@cygnus.com Wed Apr 26 16:26:00 2000
From: msnyder@cygnus.com
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: int vs. long fixups in proc-api.c
Date: Wed, 26 Apr 2000 16:26:00 -0000
Message-id: <200004262326.QAA06052@seadog.cygnus.com>
X-SW-Source: 2000-04/msg00493.html
Content-length: 3430
I will be checking in the following minor fix-ups:
2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
* proc-api.c (write_with_trace): Change 'arg' from long to int.
Treat 'off_t' and 'size_t' as unsigned long in printfs.
(lseek_with_trace): Treat 'off_t' as unsigned long in printf.
Index: proc-api.c
===================================================================
RCS file: /cvs/src/src/gdb/proc-api.c,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 proc-api.c
*** proc-api.c 2000/01/25 02:39:49 1.1.1.1
--- proc-api.c 2000/04/26 23:22:27
***************
*** 440,453 ****
int
write_with_trace (fd, arg, len, file, line)
int fd;
! long *arg;
size_t len;
char *file;
int line;
{
int i;
- long opcode = arg[0];
int ret;
if (procfs_trace)
{
--- 440,453 ----
int
write_with_trace (fd, arg, len, file, line)
int fd;
! int *arg;
size_t len;
char *file;
int line;
{
int i;
int ret;
+ int opcode = arg[0];
if (procfs_trace)
{
***************
*** 558,564 ****
if (len == sizeof (break_insn) &&
memcmp (arg, &break_insn, len) == 0)
fprintf (procfs_file ? procfs_file : stdout,
! "write (<breakpoint at 0x%08x>) \n", lseek_offset);
else if (rw_table[i].name)
fprintf (procfs_file ? procfs_file : stdout,
"write (%s) %s\n",
--- 558,565 ----
if (len == sizeof (break_insn) &&
memcmp (arg, &break_insn, len) == 0)
fprintf (procfs_file ? procfs_file : stdout,
! "write (<breakpoint at 0x%08lx>) \n",
! (unsigned long) lseek_offset);
else if (rw_table[i].name)
fprintf (procfs_file ? procfs_file : stdout,
"write (%s) %s\n",
***************
*** 568,578 ****
{
if (lseek_offset != -1)
fprintf (procfs_file ? procfs_file : stdout,
! "write (<unknown>, %d bytes at 0x%08x) \n",
! len, lseek_offset);
else
fprintf (procfs_file ? procfs_file : stdout,
! "write (<unknown>, %d bytes) \n", len);
}
break;
}
--- 569,580 ----
{
if (lseek_offset != -1)
fprintf (procfs_file ? procfs_file : stdout,
! "write (<unknown>, %lud bytes at 0x%08lx) \n",
! (unsigned long) len, (unsigned long) lseek_offset);
else
fprintf (procfs_file ? procfs_file : stdout,
! "write (<unknown>, %lud bytes) \n",
! (unsigned long) len);
}
break;
}
***************
*** 580,586 ****
if (procfs_file)
fflush (procfs_file);
}
! ret = write (fd, arg, len);
if (procfs_trace && ret != len)
{
fprintf (procfs_file ? procfs_file : stdout,
--- 582,588 ----
if (procfs_file)
fflush (procfs_file);
}
! ret = write (fd, (void *) arg, len);
if (procfs_trace && ret != len)
{
fprintf (procfs_file ? procfs_file : stdout,
***************
*** 632,638 ****
procfs_file = fopen (procfs_filename, "a");
fprintf (procfs_file ? procfs_file : stdout,
! "[lseek (0x%08x) FAILED!\n", offset);
if (procfs_file)
fflush (procfs_file);
}
--- 634,640 ----
procfs_file = fopen (procfs_filename, "a");
fprintf (procfs_file ? procfs_file : stdout,
! "[lseek (0x%08lx) FAILED!\n", (unsigned long) offset);
if (procfs_file)
fflush (procfs_file);
}
From ac131313@cygnus.com Wed Apr 26 16:29:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: multi-arch fix for monitor.c
Date: Wed, 26 Apr 2000 16:29:00 -0000
Message-id: <39077B95.D8EA5F06@cygnus.com>
References: <200004262144.OAA05362@seadog.cygnus.com> <3907743C.BDD@cygnus.com> <39077739.62400899@cygnus.com>
X-SW-Source: 2000-04/msg00494.html
Content-length: 682
Andrew Cagney wrote:
>
> Michael Snyder wrote:
> >
> > OK, try #2:
> >
> > 2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
> >
> > * monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE
> > is not static in the MULTI_ARCH world, so don't use it in a
> > static array declaration.
>
> I'm not so sure :-( MAX_REGISTER_RAW_SIZE can change and hence the
> allocated size of zerobuf could need to change.
>
> What about chaning its only use to write_register (..., 0)?
Sorry, ignore this suggestion. write_register is for high-level
accesses to GDB. As Frank suggested, it would be safer to just create
the buffer when it is needed.
Andrew
From ezannoni@cygnus.com Wed Apr 26 16:35:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] in_prologue() fix
Date: Wed, 26 Apr 2000 16:35:00 -0000
Message-id: <14599.32044.511265.33190@kwikemart.cygnus.com>
References: <14598.9829.764888.505476@kwikemart.cygnus.com> <nphfcojymh.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00495.html
Content-length: 2177
Jim Blandy writes:
>
> > It may be that the real fix is to make ecs->stop_func_start be the
> > beginning of the function where the adjusted stop_pc is. However that
> > would require several changes to H.I.E. But in any event in_prologue()
> > is wrong for this particular case.
>
> My first question is, if HIE can find enough symbolic information to
> set ecs->stop_func_{name,start,end}, how come in_prologue can't find
> it?
>
I am not sure I understand your question. in_prologue finds the start
and end of the function within which pc is (in the same way HIE does for
the wrong pc). Because of the way in_prologue works, the info found is
not compared with the input function address. Doing this would be
another way to fix the problem, but you would have to rewrite
in_prologue. What I am trying to say is that in_prologue takes 2
inputs: a pc and a function start address. It has to determine if the
pc is within the prologue of the function starting at the address. In
this case it gets it wrong because it doesn't think about checking if pc
is within the function at all.
> In other words: your explanation implies that HIE has some way to find
> the function extent, but happens to be wrong because of
> DECR_PC_AFTER_BREAK lossage. But in_prologue knows the correct PC;
> why can't it use the same mechanism HIE used earlier to get the right
> answer?
>
It does use the same mechanism (find_pc_partial_function) but it
doesn't check the results properly.
> Also, aren't there other adverse consequences when
> ecs->stop_func_{name,start,end} are wrong? I think the HIE fix is the
> right thing. HIE is painful for me too, but otherwise, you'll just
> get another CR in a month.
>
So I thought too. But in case of breakpoint being hit,
bpstat_stop_status() computes the stop_pc again, and corrects it. All
the info is printed correctly. I haven't looked at this in too much
detail though. I can add a FIXME to HIE to warn for the possibility of
problems down the road. I have no time now to try to fix this.
> If you've tested the change on SPARC and i386, it's okay with me.
I tested on sparc, I will test on linux.
Elena
From msnyder@cygnus.com Wed Apr 26 16:38:00 2000
From: msnyder@cygnus.com
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] Fixups in procfs.c
Date: Wed, 26 Apr 2000 16:38:00 -0000
Message-id: <200004262338.QAA06074@seadog.cygnus.com>
X-SW-Source: 2000-04/msg00496.html
Content-length: 3903
I will check in the following minor fix-ups in procfs:
2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
* procfs.c (comments): Eliminate "???" in comments, which GCC
wants to interpret as a trigraph. (fill_gregset, supply_gregset,
fill_fpregset, supply_fpregset): declare.
(procfs_wait): Sysargs is a long, change printf format to match.
(test-mapping, mapping_test, test_mapping_cmd) Remove (test only).
Index: procfs.c
===================================================================
RCS file: /cvs/src/src/gdb/procfs.c,v
retrieving revision 1.5
diff -c -r1.5 procfs.c
*** procfs.c 2000/04/07 04:33:21 1.5
--- procfs.c 2000/04/26 23:37:20
***************
*** 590,596 ****
* Function: create_procinfo
*
* Allocate a data structure and link it into the procinfo list.
! * (First tries to find a pre-existing one (FIXME: why???)
*
* Return: pointer to new procinfo struct.
*/
--- 590,596 ----
* Function: create_procinfo
*
* Allocate a data structure and link it into the procinfo list.
! * (First tries to find a pre-existing one (FIXME: why?)
*
* Return: pointer to new procinfo struct.
*/
***************
*** 3483,3488 ****
--- 3483,3495 ----
* is resumed.
*/
+ /* These could go in a header file, but the many and various
+ definitions of gregset_t would make it tricky... MVS */
+ extern void fill_gregset (gdb_gregset_t *, int);
+ extern void fill_fpregset (gdb_fpregset_t *, int);
+ extern void supply_gregset (gdb_gregset_t *);
+ extern void supply_fpregset (gdb_fpregset_t *);
+
static void
procfs_fetch_registers (regno)
int regno;
***************
*** 3750,3756 ****
return a "success" exit code. Bogus: what if
it returns something else? */
wstat = 0;
! retval = inferior_pid; /* ??? */
}
else
{
--- 3757,3763 ----
return a "success" exit code. Bogus: what if
it returns something else? */
wstat = 0;
! retval = inferior_pid; /* ? ? ? */
}
else
{
***************
*** 3781,3787 ****
{
printf_filtered ("%ld syscall arguments:\n", nsysargs);
for (i = 0; i < nsysargs; i++)
! printf_filtered ("#%ld: 0x%08x\n",
i, sysargs[i]);
}
--- 3788,3794 ----
{
printf_filtered ("%ld syscall arguments:\n", nsysargs);
for (i = 0; i < nsysargs; i++)
! printf_filtered ("#%ld: 0x%08lx\n",
i, sysargs[i]);
}
***************
*** 3895,3901 ****
{
printf_filtered ("%ld syscall arguments:\n", nsysargs);
for (i = 0; i < nsysargs; i++)
! printf_filtered ("#%ld: 0x%08x\n",
i, sysargs[i]);
}
}
--- 3902,3908 ----
{
printf_filtered ("%ld syscall arguments:\n", nsysargs);
for (i = 0; i < nsysargs; i++)
! printf_filtered ("#%ld: 0x%08lx\n",
i, sysargs[i]);
}
}
***************
*** 5192,5218 ****
}
- int
- mapping_test (fd, core_addr)
- int fd;
- CORE_ADDR core_addr;
- {
- printf ("File descriptor %d, base address 0x%08x\n", fd, core_addr);
- if (fd > 0)
- close (fd);
- return 0;
- }
-
- void
- test_mapping_cmd (args, from_tty)
- char *args;
- int from_tty;
- {
- int ret;
- ret = proc_iterate_over_mappings (mapping_test);
- printf ("iterate_over_mappings returned %d.\n", ret);
- }
-
void
_initialize_procfs ()
{
--- 5199,5204 ----
***************
*** 5229,5237 ****
"Cancel a trace of entries into the syscall.");
add_com ("proc-untrace-exit", no_class, proc_untrace_sysexit_cmd,
"Cancel a trace of exits from the syscall.");
-
- add_com ("test-mapping", no_class, test_mapping_cmd,
- "test iterate-over-mappings");
}
/* =================== END, GDB "MODULE" =================== */
--- 5215,5220 ----
From ac131313@cygnus.com Wed Apr 26 16:41:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: gdb/mi add section documenting proposed syntax changes
Date: Wed, 26 Apr 2000 16:41:00 -0000
Message-id: <39077E6C.C2699B3E@cygnus.com>
References: <3906B478.775F0957@cygnus.com> <200004262018.QAA24210@indy.delorie.com>
X-SW-Source: 2000-04/msg00497.html
Content-length: 559
Eli Zaretskii wrote:
>
> > Date: Wed, 26 Apr 2000 19:18:48 +1000
> > From: Andrew Cagney <ac131313@cygnus.com>
> >
> > Look ok? branch?
>
> Looks okay as far as the markup goes, except for this:
>
> > + * GDB/MI Draft 2.0 Output Syntax::
> Periods is a no-no in a node name (some Info browsers, including
> Emacs, get confused by such node names).
Ok. I've changed the title to ``Draft Changes to Output Syntax''.
> I cannot say anything about the contents, but other than that, I think
> it can go into the branch as well.
Yes, fair enough.
Andrew
From ac131313@cygnus.com Wed Apr 26 16:43:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: msnyder@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Fixups in procfs.c
Date: Wed, 26 Apr 2000 16:43:00 -0000
Message-id: <39077EE1.EB13C35D@cygnus.com>
References: <200004262338.QAA06074@seadog.cygnus.com>
X-SW-Source: 2000-04/msg00499.html
Content-length: 970
msnyder@cygnus.com wrote:
>
> I will check in the following minor fix-ups in procfs:
>
> 2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
>
> * procfs.c (comments): Eliminate "???" in comments, which GCC
> wants to interpret as a trigraph. (fill_gregset, supply_gregset,
> fill_fpregset, supply_fpregset): declare.
> (procfs_wait): Sysargs is a long, change printf format to match.
> (test-mapping, mapping_test, test_mapping_cmd) Remove (test only).
>
> + /* These could go in a header file, but the many and various
> + definitions of gregset_t would make it tricky... MVS */
> + extern void fill_gregset (gdb_gregset_t *, int);
> + extern void fill_fpregset (gdb_fpregset_t *, int);
> + extern void supply_gregset (gdb_gregset_t *);
> + extern void supply_fpregset (gdb_fpregset_t *);
> +
Michael,
This change has to be wrong. The extern declaration should be comming
from a header file somewhere.
Andrew
From msnyder@cygnus.com Wed Apr 26 16:43:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: multi-arch fix for monitor.c
Date: Wed, 26 Apr 2000 16:43:00 -0000
Message-id: <39077F1C.4D2E@cygnus.com>
References: <200004262144.OAA05362@seadog.cygnus.com> <3907743C.BDD@cygnus.com> <39077739.62400899@cygnus.com> <39077B95.D8EA5F06@cygnus.com>
X-SW-Source: 2000-04/msg00498.html
Content-length: 1026
Andrew Cagney wrote:
>
> Andrew Cagney wrote:
> >
> > Michael Snyder wrote:
> > >
> > > OK, try #2:
> > >
> > > 2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
> > >
> > > * monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE
> > > is not static in the MULTI_ARCH world, so don't use it in a
> > > static array declaration.
> >
> > I'm not so sure :-( MAX_REGISTER_RAW_SIZE can change and hence the
> > allocated size of zerobuf could need to change.
> >
> > What about chaning its only use to write_register (..., 0)?
>
> Sorry, ignore this suggestion. write_register is for high-level
> accesses to GDB. As Frank suggested, it would be safer to just create
> the buffer when it is needed.
That's why I keep you guys around. ;-)
Here is the new patch.
2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
* monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE
is not static in the MULTI_ARCH world, so don't use it in a
static array declaration.
From ac131313@cygnus.com Wed Apr 26 16:46:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Tim Mooney <mooney@dogbert.cc.ndsu.nodak.edu>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [Fwd: [Fwd: gdb 20000413 compile problem and strange SEGV problem]]
Date: Wed, 26 Apr 2000 16:46:00 -0000
Message-id: <39077F74.1F47EE94@cygnus.com>
References: <39014F1B.47DB6E05@cygnus.com>
X-SW-Source: 2000-04/msg00500.html
Content-length: 990
Andrew Cagney wrote:
>
> By ``object'' did you mean a warning or an error?
>
> > I downloaded gdb+dejagnu-20000413.tar.bz2 and encountered one problem building
> > it with the Compaq compiler: the compiler objected to comparisons between
> > {current,debug}_target.to_rcmd and tcomplain (which was being case to (void
> > *)). I'm not sure why the cast to (void *) is there at all, but my first
> > thought was to try casting tcomplain to be a pointer to a function,
> > and that worked. This is the patch I used:
>
> Your change makes sense. It was cast to (void*) since the functions
> to_rcmd() and tcomplain() were not type incompatible. The compaq
> compiler is more picky about such things.
FYI,
I've just checked and GDB-5.0 build on an ``OSF1 V4.0 464 alpha'' using
both GCC and the native CC. I'll assume that these were compiler
warnings rather than fatal compiler errors. Consequently the cleanups
should get merged into the trunk but not the GDB-5.0 branch.
Andrew
From msnyder@cygnus.com Wed Apr 26 16:54:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Fixups in procfs.c
Date: Wed, 26 Apr 2000 16:54:00 -0000
Message-id: <390781C8.5838@cygnus.com>
References: <200004262338.QAA06074@seadog.cygnus.com> <39077EE1.EB13C35D@cygnus.com>
X-SW-Source: 2000-04/msg00501.html
Content-length: 1895
Andrew Cagney wrote:
>
> msnyder@cygnus.com wrote:
> >
> > I will check in the following minor fix-ups in procfs:
> >
> > 2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
> >
> > * procfs.c (comments): Eliminate "???" in comments, which GCC
> > wants to interpret as a trigraph. (fill_gregset, supply_gregset,
> > fill_fpregset, supply_fpregset): declare.
> > (procfs_wait): Sysargs is a long, change printf format to match.
> > (test-mapping, mapping_test, test_mapping_cmd) Remove (test only).
> >
>
> > + /* These could go in a header file, but the many and various
> > + definitions of gregset_t would make it tricky... MVS */
> > + extern void fill_gregset (gdb_gregset_t *, int);
> > + extern void fill_fpregset (gdb_fpregset_t *, int);
> > + extern void supply_gregset (gdb_gregset_t *);
> > + extern void supply_fpregset (gdb_fpregset_t *);
> > +
>
> Michael,
>
> This change has to be wrong. The extern declaration should be comming
> from a header file somewhere.
I appreciate the sentiment (as reflected by my comment).
There are currently 15 (fifteen) implementations of these
four functions. Thirteen of them have an argument of type
"gregset_t", one has a "prgregset_t", and one has an
"elf_gregset_t". None of these functions is declared in any
header file. The type itself comes from various different
system header files, depending on the native OS.
To cope with this divergence, procfs has its own typedef
"gdb_gregset_t" which is declared in various different ways
inside an ugly ifdef. It calls the function with that, and
if all goes well, the actual argument will match the appropriate
version of the formal argument.
I did not think this ugliness ought to be exported up
into a local header file, since there are very few users
of this API. And anyway, I was only trying to suppress
a compiler warning.
From ac131313@cygnus.com Wed Apr 26 16:56:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: Guy Harris <guy@netapp.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: Patch to make top-of-tree GDB compile on Digital UNIX
Date: Wed, 26 Apr 2000 16:56:00 -0000
Message-id: <390781AF.AB20C802@cygnus.com>
References: <200004220016.RAA02113@tooting> <14596.24388.209049.765129@kwikemart.cygnus.com>
X-SW-Source: 2000-04/msg00502.html
Content-length: 1930
Elena Zannoni wrote:
> Index: osfsolib.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/osfsolib.c,v
> retrieving revision 1.2
> diff -c -r1.2 osfsolib.c
> *** osfsolib.c 2000/04/04 02:08:52 1.2
> --- osfsolib.c 2000/04/24 14:42:07
> ***************
> *** 598,604 ****
> text_addr = bfd_section_vma (so->abfd, lowest_sect) + LM_OFFSET (so);
> }
>
> ! section_addrs.text_addr = text_addr;
> so->objfile = symbol_file_add (so->so_name, so->from_tty,
> §ion_addrs, 0, OBJF_SHARED);
> return (1);
> --- 598,605 ----
> text_addr = bfd_section_vma (so->abfd, lowest_sect) + LM_OFFSET (so);
> }
>
> ! section_addrs.other[0].addr = text_addr;
> ! section_addrs.other[0].name = ".text";
> so->objfile = symbol_file_add (so->so_name, so->from_tty,
> §ion_addrs, 0, OBJF_SHARED);
> return (1);
>
I see Elena is working through all the fixes like the above (Thanks)!
> I don't think we have a maintainer for this platform, do we?
> Elena
Which means it is me ....
> > I also changed "symbol_add_stub()" and "solib_map_sections()" to take a
> > "PTR" rather than a "char *" as an argument, similar to the signatures
> > they have in other "*solib.c" files, to eliminate some compiler
> > warnings; Elena Zannoni suggested to me that "PTR" is deprecated in
> > favor of "void *", so perhaps "void *" should be used instead.
That is correct. The output of `grep PTR *.[hc] | wc -l` should be
going down not up :-)
Elena also noted that the patch combined two very different changes.
It's really important to keep cleanups separate from bug fixes. You may
find it easier if you have two or more copies of the the GDB source
tree. That way one tree can be used to create clean patches while
another is used for experimentation.
enjoy,
Andrew
From ac131313@cygnus.com Wed Apr 26 17:04:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Fixups in procfs.c
Date: Wed, 26 Apr 2000 17:04:00 -0000
Message-id: <390783BF.F84078D4@cygnus.com>
References: <200004262338.QAA06074@seadog.cygnus.com> <39077EE1.EB13C35D@cygnus.com> <390781C8.5838@cygnus.com>
X-SW-Source: 2000-04/msg00503.html
Content-length: 1160
Michael Snyder wrote:
>
> > Michael,
> >
> > This change has to be wrong. The extern declaration should be comming
> > from a header file somewhere.
>
> I appreciate the sentiment (as reflected by my comment).
> There are currently 15 (fifteen) implementations of these
> four functions. Thirteen of them have an argument of type
> "gregset_t", one has a "prgregset_t", and one has an
> "elf_gregset_t". None of these functions is declared in any
> header file. The type itself comes from various different
> system header files, depending on the native OS.
>
> To cope with this divergence, procfs has its own typedef
> "gdb_gregset_t" which is declared in various different ways
> inside an ugly ifdef. It calls the function with that, and
> if all goes well, the actual argument will match the appropriate
> version of the formal argument.
>
> I did not think this ugliness ought to be exported up
> into a local header file, since there are very few users
> of this API. And anyway, I was only trying to suppress
> a compiler warning.
Ok (ulgh).
I'd suggest expanding on the comment a little with what you've explained
above.
sorry,
Andrew
From guy@netapp.com Wed Apr 26 17:06:00 2000
From: Guy Harris <guy@netapp.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, Guy Harris <guy@netapp.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: Patch to make top-of-tree GDB compile on Digital UNIX
Date: Wed, 26 Apr 2000 17:06:00 -0000
Message-id: <200004270006.RAA24862@tooting>
References: <390781AF.AB20C802@cygnus.com>
X-SW-Source: 2000-04/msg00504.html
Content-length: 848
> Elena also noted that the patch combined two very different changes.
If you're referring to her comment
Your changes to symbol_add_stub are actually more than what
necessary for compilation. You have added the use of the
function build_section_addr_info_from_section_table() which
Kevin Buettner introduced for other purposes a few weeks back.
it was, at least as I was constructing it, only one change, as I'd
inferred, perhaps incorrectly, from other changes that the changes to
use "build_section_addr_info_from_section_table()" *were* the way to fix
the compilation problem; they weren't an attempt on my part to
experimentally clean the code up.
I don't particularly care how it's fixed, as long as it compiles and
works; if the changes Elena suggested are sufficient to get it to build
and work, you might as well go with those.
From ac131313@cygnus.com Wed Apr 26 17:08:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: David Whedon <davidw@gordian.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: problem with 5.0 branch building on irix (arm target)
Date: Wed, 26 Apr 2000 17:08:00 -0000
Message-id: <3907848E.B4FCF4FE@cygnus.com>
References: <Pine.LNX.4.04.10004181743530.19907-100000@pcx08>
X-SW-Source: 2000-04/msg00505.html
Content-length: 196
David Whedon wrote:
>
> Maybe my situation is too obscure, and you all shouldn't be bothered. If
> so let me know.
I've not seen any responses so I've added a note to the TODO file :-(
Andrew
From msnyder@cygnus.com Wed Apr 26 17:14:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: David Taylor <taylor@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [RFC]: internal_error should call target_terminal_ours
Date: Wed, 26 Apr 2000 17:14:00 -0000
Message-id: <3907866D.1844@cygnus.com>
References: <200003292312.SAA26979@texas.cygnus.com> <38E29C4F.72C114E3@cygnus.com>
X-SW-Source: 2000-04/msg00506.html
Content-length: 2462
Andrew Cagney wrote:
>
> David Taylor wrote:
> >
> > Date: Wed, 29 Mar 2000 12:10:02 -0800
> > From: Michael Snyder <msnyder@cygnus.com>
> >
> > I just encountered a situation where internal_error was called
> > while the target program was running, resulting in the following:
> >
> > gdb-internal-error: gdbarch: gdbarch_breakpoint_from_pc invalid
> > An internal GDB error was detected. This may make make further
> > debugging unreliable. Continue this debugging session? (y or n)
> > Suspended (tty input)
> > %] msnyder<547>%
> >
> > As you can see, instead of waiting for my input, GDB suspended
> > because it didn't own the tty.
> >
> > It's probably a bad thing (tm) to call internal_error while the
> > inferior is running, but in case it does happen, I wonder what
> > people think about the following?
> >
> > I think that you're right that adding target_terminal_ours would be a
> > good thing. But, my inclination is to put it closer to the actual i/o
> > -- namely in internal_verror rather than internal_error.
> >
> > Additionally, looking at internal_verror, I think that it should call
> > quit_force rather than calling exit -- as it is now it just abandons
> > the target.
>
> My only thought is that I'm not sure if target_terminal_ours() is
> idenpotent. See remote.c where, due to async, it was being called
> multiple times. I ended up adding code to make the functions
> idenpotent. Should that code be moved to target.c?
>
> David's made a good point. Everything goes through internal_verror().
> Hey, i planned it that way :-)
Oops -- I let this one sleep in my sandbox for a while.
Since no one else has chimed in, I will make the change
that Andrew and David suggested, and check it in.
Here is the change for posterity:
2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
* utils.c (internal_verror): Call target_terminal_ours.
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.7
diff -c -r1.7 utils.c
*** utils.c 2000/04/21 04:10:18 1.7
--- utils.c 2000/04/27 00:13:21
***************
*** 680,685 ****
--- 680,686 ----
}
/* Try to get the message out */
+ target_terminal_ours ();
fputs_unfiltered ("gdb-internal-error: ", gdb_stderr);
vfprintf_unfiltered (gdb_stderr, fmt, ap);
fputs_unfiltered ("\n", gdb_stderr);
From jimb@zwingli.cygnus.com Wed Apr 26 17:25:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: print addresses that are longer than pointers
Date: Wed, 26 Apr 2000 17:25:00 -0000
Message-id: <200004270025.TAA03409@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00507.html
Content-length: 2307
This is yet a third amendment to address printing in printcmd.c.
I recently made changes which allow GDB to handle architectures on
which addresses are larger than pointers. However, the code which
Peter Schauer added to printcmd.c to handle unwanted sign extension
assumes that addresses and pointers are the same size.
As it turns out, this masking is unnecessary when the value being
printed is a genuine pointer; the sign extension won't occur, and the
masking is unneeded.
This also rewrites the mask generation in a way which I think is
overflow-free, without needing to pull the wool over the compiler's
eyes.
2000-04-26 Jim Blandy <jimb@redhat.com>
* printcmd.c (print_scalar_formatted): Addresses may be longer
than pointers. If the value we're printing is a genuine pointer,
assume that unpack_pointer will do the right thing.
Index: gdb/printcmd.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/printcmd.c,v
retrieving revision 1.163
diff -c -r1.163 printcmd.c
*** gdb/printcmd.c 2000/04/16 14:53:33 1.163
--- gdb/printcmd.c 2000/04/27 00:20:36
***************
*** 444,457 ****
case 'a':
{
! /* Truncate address to the size of a target pointer, avoiding
! shifts larger or equal than the width of a CORE_ADDR. The
! local variable PTR_BIT stops the compiler reporting a shift
! overflow when it won't occure. */
CORE_ADDR addr = unpack_pointer (type, valaddr);
! int ptr_bit = TARGET_PTR_BIT;
! if (ptr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
! addr &= ((CORE_ADDR) 1 << ptr_bit) - 1;
print_address (addr, stream);
}
break;
--- 444,459 ----
case 'a':
{
! /* If the value is actually a pointer, then unpack_pointer
! will do the right thing. If the value is not a pointer,
! but happens to be a signed type, then unpack_pointer may
! sign-extend it; in this case, we trim it to the size of a
! pointer. */
CORE_ADDR addr = unpack_pointer (type, valaddr);
! if (TYPE_CODE (type) != TYPE_CODE_PTR)
! /* When building the mask, avoid shifts larger or equal than
! the width of a CORE_ADDR. */
! addr &= (((CORE_ADDR) 1 << (TARGET_PTR_BIT - 1)) << 1) + 1;
print_address (addr, stream);
}
break;
From msnyder@cygnus.com Wed Apr 26 17:27:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [RFC]: export write_register_gen
Date: Wed, 26 Apr 2000 17:27:00 -0000
Message-id: <39078958.24CC@cygnus.com>
X-SW-Source: 2000-04/msg00508.html
Content-length: 1110
The module findvar.c has at least three different interfaces
for accessing GDB's internal cache of register values:
CORE_ADDR read_register (int regno);
void write_register (int regno, LONGEST val);
void read_register_bytes (int inregbyte, char *myaddr, int inlen);
void write_register_bytes (int inregbyte, char *myaddr, int inlen);
void read_register_gen (int regno, char *myaddr);
static void write_register_gen (int regno, char *myaddr);
If you're dealing with a host LONGEST or CORE_ADDR,
then the preferred interface is read_register/write_register.
However if you're dealing with a buffer of bytes in target
byte order, you would use one of the other two. And by far
the easiest to use is [read/write]_register_gen. You would
only need to use [read/write]_register_bytes if the stream
of bytes you have might cross the boundary between two registers
(or start in the middle of one).
Yet write_register_gen is declared static. I thought I was
going to need it, so I wanted to export it. It turns out that
I don't need it, but I still think it should be public.
Thoughts?
Michael
From jimb@zwingli.cygnus.com Wed Apr 26 17:29:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: RECALL PATCH: print addresses that are longer than pointers
Date: Wed, 26 Apr 2000 17:29:00 -0000
Message-id: <200004270029.TAA03414@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00509.html
Content-length: 100
My patch reintroduces the regression Peter was trying to fix in the
first place. I'll resubmit it.
From ac131313@cygnus.com Wed Apr 26 17:33:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>, powerpc-psim@ci.com.au
Subject: [psim] Fix to events.c assertion failure
Date: Wed, 26 Apr 2000 17:33:00 -0000
Message-id: <39078A7E.857D58AD@cygnus.com>
X-SW-Source: 2000-04/msg00510.html
Content-length: 4349
Hello,
The attatched patch hopefully fixes an assertion failure in events.c
that several people were reporting. Can people please let me know how
it goes (quickly, the 5.0 boat is now departing...)
I should note that the patch as it stands contains additions to the
event tracing, I'll be separating that out when it comes to the actual
checkin.
Andrew
Wed Apr 26 16:08:42 2000 Andrew Cagney <cagney@b1.cygnus.com>
* events.c (event_queue_process): Call update_time_from_event
every time an event is removed from the queue.
(update_time_from_event): Delete assertion that a negative
time_from_event implies an empty event queue. Add more tracing.
Index: events.c
===================================================================
RCS file: /cvs/src/src/sim/ppc/events.c,v
retrieving revision 1.1.1.1
diff -p -r1.1.1.1 events.c
*** events.c 1999/04/16 01:35:09 1.1.1.1
--- events.c 2000/04/26 06:33:28
*************** update_time_from_event(event_queue *even
*** 161,168 ****
events->time_of_event = current_time - 1;
events->time_from_event = -1;
}
ASSERT(current_time == event_queue_time(events));
- ASSERT((events->time_from_event >= 0) == (events->queue != NULL));
}
STATIC_INLINE_EVENTS\
--- 161,185 ----
events->time_of_event = current_time - 1;
events->time_from_event = -1;
}
+ if (WITH_TRACE && ppc_trace[trace_events])
+ {
+ event_entry *event;
+ int i;
+ for (event = events->queue, i = 0;
+ event != NULL;
+ event = event->next, i++)
+ {
+ TRACE(trace_events, ("event time-from-event - time %ld, delta %ld - event %d, tag 0x%lx, time %ld, handler 0x%lx, data 0x%lx\n",
+ (long)current_time,
+ (long)events->time_from_event,
+ i,
+ (long)event,
+ (long)event->time_of_event,
+ (long)event->handler,
+ (long)event->data));
+ }
+ }
ASSERT(current_time == event_queue_time(events));
}
STATIC_INLINE_EVENTS\
*************** event_queue_process(event_queue *events)
*** 369,386 ****
event_handler *handler = to_do->handler;
void *data = to_do->data;
events->queue = to_do->next;
! TRACE(trace_events, ("event issued at %ld - tag 0x%lx - handler 0x%lx, data 0x%lx\n",
(long)event_time,
(long)to_do,
(long)handler,
(long)data));
zfree(to_do);
handler(data);
}
events->processing = 0;
! /* re-caculate time for new events */
! update_time_from_event(events);
}
--- 386,407 ----
event_handler *handler = to_do->handler;
void *data = to_do->data;
events->queue = to_do->next;
! TRACE(trace_events, ("event issued at %ld - tag 0x%lx - time %ld, handler 0x%lx, data 0x%lx\n",
(long)event_time,
(long)to_do,
+ (long)to_do->time_of_event,
(long)handler,
(long)data));
zfree(to_do);
+ /* Always re-compute the time to the next event so that HANDLER()
+ can safely insert new events into the queue. */
+ update_time_from_event(events);
handler(data);
}
events->processing = 0;
! ASSERT(events->time_from_event > 0);
! ASSERT(events->queue != NULL); /* always poll event */
}
Index: interrupts.c
===================================================================
RCS file: /cvs/src/src/sim/ppc/interrupts.c,v
retrieving revision 1.1.1.2
diff -p -r1.1.1.2 interrupts.c
*** interrupts.c 1999/04/26 18:33:26 1.1.1.2
--- interrupts.c 2000/04/26 06:33:28
*************** deliver_hardware_interrupt(void *data)
*** 469,475 ****
unsigned_word cia = cpu_get_program_counter(processor);
unsigned_word nia = perform_oea_interrupt(processor,
cia, 0x00900, 0, 0, 0, 0);
! TRACE(trace_interrupts, ("decrementer interrupt - cia=0x%lx time=0x%lx\n",
(unsigned long)cia,
(unsigned long)event_queue_time(psim_event_queue(cpu_system(processor)))
));
--- 469,475 ----
unsigned_word cia = cpu_get_program_counter(processor);
unsigned_word nia = perform_oea_interrupt(processor,
cia, 0x00900, 0, 0, 0, 0);
! TRACE(trace_interrupts, ("decrementer interrupt - cia 0x%lx, time %ld\n",
(unsigned long)cia,
(unsigned long)event_queue_time(psim_event_queue(cpu_system(processor)))
));
From msnyder@cygnus.com Wed Apr 26 17:39:00 2000
From: msnyder@cygnus.com
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: testsuite tweak for Sparclet
Date: Wed, 26 Apr 2000 17:39:00 -0000
Message-id: <200004270038.RAA06208@seadog.cygnus.com>
X-SW-Source: 2000-04/msg00511.html
Content-length: 2093
The sparclet remote stub does not support stdio, so these tests,
which depend on parsing the output of the program, will never run.
There are probably others with the same problem -- these are just
the ones I happened to catch.
2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
* gdb.base/call-ar-st.exp: Bail out if target is sparclet.
This test depends on parsing the printf output from the target.
Since the sparclet stub doesn't do stdio, this will never work.
* gdb.base/call-rt-st.exp: ditto.
Index: gdb.base/call-ar-st.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/call-ar-st.exp,v
retrieving revision 1.3
diff -p -r1.3 call-ar-st.exp
*** call-ar-st.exp 2000/04/08 05:10:43 1.3
--- call-ar-st.exp 2000/04/27 00:37:13
*************** set testfile "call-ar-st"
*** 32,37 ****
--- 32,40 ----
set srcfile ${testfile}.c
set binfile ${objdir}/${subdir}/${testfile}
+ if { [istarget "sparclet-*-*"] } {
+ return 0;
+ }
if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
*************** gdb_expect {
*** 567,571 ****
}
return
- ~
--- 570,574 ----
}
return
+
Index: gdb.base/call-rt-st.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/call-rt-st.exp,v
retrieving revision 1.1.1.3
diff -p -r1.1.1.3 call-rt-st.exp
*** call-rt-st.exp 1999/06/28 16:02:48 1.1.1.3
--- call-rt-st.exp 2000/04/27 00:37:13
*************** set srcfile ${testfile}.c
*** 36,41 ****
--- 36,45 ----
set binfile ${objdir}/${subdir}/${testfile}
+ if { [istarget "sparclet-*-*"] } {
+ return 0;
+ }
+
if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug additional_flags=-w}] != "" } {
gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
}
From msnyder@cygnus.com Wed Apr 26 18:10:00 2000
From: msnyder@cygnus.com
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: multi-arch tweak for sparclet-rom.c
Date: Wed, 26 Apr 2000 18:10:00 -0000
Message-id: <200004270110.SAA06267@seadog.cygnus.com>
X-SW-Source: 2000-04/msg00512.html
Content-length: 2251
To get away from using the REGISTER_NAMES macro, it's necessary to
initialize this local array of register names explicitly. I know it
is ugly to just duplicate the list of names found in the tm.h file,
but that is what most other existing rom modules do. The monitor
mechanism depends on having its own local copy of this array of
string names.
2000-04-26 Michael Snyder <msnyder@seadog.cygnus.com>
* sparclet-rom.c (sparclet_regnames): Initialize this array
explicitly rather than use the REGISTER_NAMES macro (which must
eventually go away for Multi-Arch).
Index: sparclet-rom.c
===================================================================
RCS file: /cvs/src/src/gdb/sparclet-rom.c,v
retrieving revision 1.1.1.2
diff -c -r1.1.1.2 sparclet-rom.c
*** sparclet-rom.c 1999/07/07 20:10:12 1.1.1.2
--- sparclet-rom.c 2000/04/27 01:07:58
***************
*** 61,67 ****
/* is wim part of psr?? */
/* monitor wants lower case */
! static char *sparclet_regnames[NUM_REGS] = REGISTER_NAMES;
/* Function: sparclet_supply_register
--- 61,92 ----
/* is wim part of psr?? */
/* monitor wants lower case */
! static char *sparclet_regnames[] = {
! "g0", "g1", "g2", "g3", "g4", "g5", "g6", "g7",
! "o0", "o1", "o2", "o3", "o4", "o5", "o6", "o7",
! "l0", "l1", "l2", "l3", "l4", "l5", "l6", "l7",
! "i0", "i1", "i2", "i3", "i4", "i5", "i6", "i7",
!
! "", "", "", "", "", "", "", "", /* no FPU regs */
! "", "", "", "", "", "", "", "",
! "", "", "", "", "", "", "", "",
! "", "", "", "", "", "", "", "",
! /* no CPSR, FPSR */
! "y", "psr", "wim", "tbr", "pc", "npc", "", "",
!
! "ccsr", "ccpr", "cccrcr", "ccor", "ccobr", "ccibr", "ccir", "",
!
! /* ASR15 ASR19 (don't display them) */
! "asr1", "", "asr17", "asr18", "", "asr20", "asr21", "asr22",
! /*
! "awr0", "awr1", "awr2", "awr3", "awr4", "awr5", "awr6", "awr7",
! "awr8", "awr9", "awr10", "awr11", "awr12", "awr13", "awr14", "awr15",
! "awr16", "awr17", "awr18", "awr19", "awr20", "awr21", "awr22", "awr23",
! "awr24", "awr25", "awr26", "awr27", "awr28", "awr29", "awr30", "awr31",
! "apsr",
! */
! };
!
/* Function: sparclet_supply_register
From mooney@dogbert.cc.ndsu.nodak.edu Wed Apr 26 18:15:00 2000
From: Tim Mooney <mooney@dogbert.cc.ndsu.nodak.edu>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [Fwd: [Fwd: gdb 20000413 compile problem and strange SEGVproblem]]
Date: Wed, 26 Apr 2000 18:15:00 -0000
Message-id: <Pine.OSF.4.21.0004262006430.31704-100000@dogbert.cc.ndsu.nodak.edu>
References: <39077F74.1F47EE94@cygnus.com>
X-SW-Source: 2000-04/msg00513.html
Content-length: 2078
In regard to: Re: [Fwd: [Fwd: gdb 20000413 compile problem and strange SEGV...:
>Andrew Cagney wrote:
>>
>> By ``object'' did you mean a warning or an error?
>>
>> > I downloaded gdb+dejagnu-20000413.tar.bz2 and encountered one problem building
>> > it with the Compaq compiler: the compiler objected to comparisons between
>> > {current,debug}_target.to_rcmd and tcomplain (which was being case to (void
>> > *)). I'm not sure why the cast to (void *) is there at all, but my first
>> > thought was to try casting tcomplain to be a pointer to a function,
>> > and that worked. This is the patch I used:
>>
>> Your change makes sense. It was cast to (void*) since the functions
>> to_rcmd() and tcomplain() were not type incompatible. The compaq
>> compiler is more picky about such things.
>
>FYI,
>
>I've just checked and GDB-5.0 build on an ``OSF1 V4.0 464 alpha'' using
>both GCC and the native CC. I'll assume that these were compiler
>warnings rather than fatal compiler errors. Consequently the cleanups
>should get merged into the trunk but not the GDB-5.0 branch.
Andrew-
Thanks for looking into this.
They were errors, not warnings. The build stopped at that point. This was
with the latest version of the vendor compiler on alpha-dec-osf4.0f (4.0f ==
Rev 1229, you can tell what the letter version is by running `sizer -v').
I don't know if I tried this on my 5.0 box at home, but I don't think so.
I think rev 464 is osf4.0b, which has a compiler that may not be as recent
as the current patched compiler on the later versions of the OS.
If you want to email me how I can get access to the 5.0 tree, I'll happily
test the build on a few different versions of the OS, including my 5.x box
at home. If I just do a `cvs checkout' will I get the 5.0 tree, or do I have
to do something special?
Tim
--
Tim Mooney mooney@dogbert.cc.ndsu.NoDak.edu
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
^ permalink raw reply [flat|nested] 3+ messages in thread