This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: Fix for call-ar-st.exp failure on x86
> In principle, we should send patches back to the author for revision,
> but these problems are pretty easy to fix, and I'm especially happy
> to get rid of those call-ar-st.exp failures.
Thanks for cleaning up after me. I had been planning to eventually do
something about the gdbarch-friendliness thing but I didn't notice the
big-endian and garbage-reading things (duh....).
I'm a bit shy about submitting lots of patches (and revisions thereto)
until I can get our paperwork in (Real Soon Now, I'm assured :-)). Of
course, small changes don't require it, so perhaps I am being too
timid.
> If you see anything dumb, let me know.
Well, since you mention it :-). Here is a fix to an uninitialized
variable:
1999-10-12 Jim Kingdon <http://developer.redhat.com>
* valops.c (value_push): Initialize container_len even if
PARM_BOUNDARY is zero.
Index: valops.c
===================================================================
RCS file: /cvs/gdb/gdb/gdb/valops.c,v
retrieving revision 1.1.1.8
diff -u -r1.1.1.8 valops.c
--- valops.c 1999/10/12 04:37:25 1.1.1.8
+++ valops.c 1999/10/12 21:23:31
@@ -1081,6 +1081,8 @@
if (PARM_BOUNDARY)
container_len = ((len + PARM_BOUNDARY / TARGET_CHAR_BIT - 1)
& ~(PARM_BOUNDARY / TARGET_CHAR_BIT - 1));
+ else
+ container_len = len;
/* Are we going to put it at the high or low end of the container? */
if (TARGET_BYTE_ORDER == BIG_ENDIAN)