From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb@sources.redhat.com, cgf@cygnus.com
Subject: [RFC] Sanitize i386 targets
Date: Thu, 10 May 2001 11:24:00 -0000 [thread overview]
Message-ID: <200105101824.f4AIO1M00251@delius.kettenis.local> (raw)
In a hope to multi-arch the i386 targets, i'm trying to cleanup the
target dependent stuff in the config/i386 directory. In doing so, I
noticed that quite a few targets make use of the tm-i386v.h file.
This file is supposed to give target dependent definitions for System
V-derived systems (presumably release III, a.k.a. SVR3), but quite a
few targets including this file bear no resemblence to UNIX at all.
Most of these are the "embedded" targets, i.e. i386-elf, i386-aout,
i386-coff, vxWorks. Another example is Cygwin. It would make more
sense to me if these targets used the "tm-i386.h" header directly.
Now what exactly does "tm-i386v.h" provide that "tm-i386.h" doesn't?
Hardly anything. In fact it overrides some stuff from "tm-i386.h"
with code that provides less functionality:
1. EXTRACT_RETURN_VALUE and STORE_RETURN_VALUE:
These are implemented as a simple memcpy. I suspect that even SVR3
used the same conventions for return values as the current
SVR4/i386 ABI (except perhaps for small structs). Basically, this
means that only simple scalar return values (integers up to 32 bits
and pointers) are supported. No 64-bit integers and probably no
floating point return values. It's also very likely that returning
small structs won't work right.
I'm fairly sure that the implementation provided by "tm-i386.h"
does the right thing for all supported i?86 targets (except the
symmetry, which provides its own version of EXTRACT_RETURN_VALUE
anyway). Therefore I propose to zap these macros from
"tm-i386v.h".
2. FRAMELESS_FUNCTION_INVOCATION, FRAME_SAVED_PC, FRAME_NUM_ARGS:
These are almost identical to the ones provided by "tm-i386.h",
except that the logic to handle signal handler frames is absent.
Previously the version of FRAME_SAVED_PC in "tm-i386.h" caused a
linker failure for targets that didn't implement
sigtramp_saved_pc. That's probably the reason why these targets
used "tm-i386v.h" in the first place. However I recently checked
in some changes to overcome this problem. The additional signal
handler frame logic shouldn't do any harm since none of these
targets define IN_SIGTRAMP and therefore never flag any frames as
corresponding to a signal handler. So these can be zapped too.
In the end zapping these macros leaves only
START_INFERIOR_TRAPS_EXPECTED. Now that's a bit of SVR3-specific
information. But it's irrelevant to non-SVR3 targets, so I think
those can simply use "tm-i386.h". Building a i386-elf or i386-cygwin
cross debugger with such a change does indeed succeed. Unfortunately
I cannot really check if such a cross debugger does indeed work. So I
would appreciate it if someone who can test such a compiler could do
so. Try to get GDB to display the return value of test_return() in
the following program:
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
long long
test_return (void)
{
return 2 * LONG_MAX;
}
int
main (void)
{
printf ("test_return returned %Ld\n", test_return ());
return EXIT_SUCCESS;
}
A preliminary patch is attached.
Comments are also very welcome.
Thanks,
Mark
Index: config/i386/tm-i386v.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-i386v.h,v
retrieving revision 1.6
diff -u -p -r1.6 tm-i386v.h
--- config/i386/tm-i386v.h 2001/05/08 12:00:49 1.6
+++ config/i386/tm-i386v.h 2001/05/10 18:16:30
@@ -24,7 +24,6 @@
/* First pick up the generic *86 target file. */
-#include "regcache.h"
#include "i386/tm-i386.h"
/* Number of traps that happen between exec'ing the shell to run an
@@ -33,52 +32,5 @@
#undef START_INFERIOR_TRAPS_EXPECTED
#define START_INFERIOR_TRAPS_EXPECTED 4
-
-/* Extract from an array REGBUF containing the (raw) register state
- a function return value of type TYPE, and copy that, in virtual format,
- into VALBUF. */
-
-#undef EXTRACT_RETURN_VALUE
-#define EXTRACT_RETURN_VALUE(TYPE,REGBUF,VALBUF) \
- memcpy ((VALBUF), (REGBUF), TYPE_LENGTH (TYPE))
-
-/* Write into appropriate registers a function return value
- of type TYPE, given in virtual format. */
-
-#undef STORE_RETURN_VALUE
-#define STORE_RETURN_VALUE(TYPE,VALBUF) \
- write_register_bytes (0, VALBUF, TYPE_LENGTH (TYPE))
-\f
-
-/* Describe the pointer in each stack frame to the previous stack frame
- (its caller). */
-
-/* FRAME_CHAIN takes a frame's nominal address
- and produces the frame's chain-pointer. */
-
-#undef FRAME_CHAIN
-#define FRAME_CHAIN(thisframe) \
- (!inside_entry_file ((thisframe)->pc) ? \
- read_memory_integer ((thisframe)->frame, 4) :\
- 0)
-
-/* Define other aspects of the stack frame. */
-
-/* A macro that tells us whether the function invocation represented
- by FI does not have a frame on the stack associated with it. If it
- does not, FRAMELESS is set to 1, else 0. */
-
-#undef FRAMELESS_FUNCTION_INVOCATION
-#define FRAMELESS_FUNCTION_INVOCATION(FI) \
- (frameless_look_for_prologue (FI))
-
-#undef FRAME_SAVED_PC
-#define FRAME_SAVED_PC(FRAME) (read_memory_integer ((FRAME)->frame + 4, 4))
-
-/* Return number of args passed to a frame.
- Can return -1, meaning no way to tell. */
-
-#undef FRAME_NUM_ARGS
-#define FRAME_NUM_ARGS(fi) (-1)
#endif /* ifndef TM_I386V_H */
reply other threads:[~2001-05-10 11:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200105101824.f4AIO1M00251@delius.kettenis.local \
--to=kettenis@wins.uva.nl \
--cc=cgf@cygnus.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox