Re: copyright assignment
On 11/22/2009 10:48 AM, John Nowak wrote: Hello. I would like to get the necessary forms for copyright assignment to GCC for future work on GNAT. I was told this is the way to kick off the process. I sent them offlist. Paolo
[cygwin-1.7] bootstrap failure: ../../gcc/gcc/config/i386/i386.c:24542:24: error: comparison between signed and unsigned integer expressions
Seems to me that http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00648.html might cause this: /usr/local/src/trunk/objdir/./prev-gcc/xgcc -B/usr/local/src/trunk/objdir/./prev-gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem /usr/local/gnu/i686-pc-cygwin/include -isystem /usr/local/gnu/i686-pc-cygwin/sys-include-c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -Iyes/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -DCLOOG_PPL_BACKEND\ ../../gcc/gcc/config/i386/i386.c -o i386.o cc1: warnings being treated as errors ../../gcc/gcc/config/i386/i386.c: In function 'avx_vpermilp_parallel': ../../gcc/gcc/config/i386/i386.c:24542:24: error: comparison between signed and unsigned integer expressions make[3]: *** [i386.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' Windows XP Pro/SP3 cygwin Intel Core2 Duo t9...@2.80ghz system with packages: binutils 2.19.51-1 2.19.51.20090704 bison2.3-1 2.3 cloog-ppl0.15.3-1 cygwin 1.7.0-65 dejagnu 20021217-2 1.4.2.x expect 20030128-1 5.26 gcc4-ada 4.3.4-1 gcc4-core4.3.4-1 gcc4-g++ 4.3.4-1 gmp 4.3.1-3 libcloog-devel 0.15.3-1 libgmp-devel 4.3.1-3 libmpc-devel 0.8-1 libmpfr-devel2.4.1-4 libppl 0.10.2-1 make 3.81-2 mpclib 0.8-1 mpfr 2.4.1-4 ppl 0.10.2-1 ppl-devel0.10.2-1 tcltk20080420-1 8.4 w32api 3.14-1 LAST_UPDATED: Mon Nov 23 06:25:08 UTC 2009 (revision 154431) This is on -- Cheers, /ChJ
Re: BUG: GCC-4.4.x changes the function frame on some functions
On Thu, Nov 19, 2009 at 08:01:57PM +0100, Thomas Gleixner wrote: > Just compiled with -mincoming-stack-boundary=4 and the problem goes > away as gcc now thinks that the incoming stack is already 16 byte > aligned. But that might break code which actually uses SSE Please don't do this, lying to the compiler is just going to result in wrong-code sooner or later, with the above switch gcc will assume the incoming stack is 16-byte aligned (which is not true in the ix86 kernel) and could very well e.g. optimize away code that looks at alignment of stack variables etc. Jakub
Re: BUG: GCC-4.4.x changes the function frame on some functions
On Mon, 23 Nov 2009, Jakub Jelinek wrote: > On Thu, Nov 19, 2009 at 08:01:57PM +0100, Thomas Gleixner wrote: > > Just compiled with -mincoming-stack-boundary=4 and the problem goes > > away as gcc now thinks that the incoming stack is already 16 byte > > aligned. But that might break code which actually uses SSE > > Please don't do this, lying to the compiler is just going to result in > wrong-code sooner or later, with the above switch gcc will assume the > incoming stack is 16-byte aligned (which is not true in the ix86 kernel) > and could very well e.g. optimize away code that looks at > alignment of stack variables etc. Right. I gave up the idea pretty fast. But in the current situation we are forced to lie to the compiler in some way. Forcing -mtune=generic when the function graph tracer is enabled seems to be a halfways sane work around. Thanks, tglx
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
Ok, now that 3.4.6 is fully working, I made a start on the 4.4 port.
4.4 appears to have invalidated a lot of 3.4.6 things. Below are all
the changes I needed to make just to get an xgcc executable
built. I didn't really know what most of it was about, but the
purpose was just to scope the changes. Any changes that need
to be done to 4.4 I can now refer to how it was accomplished
in 3.4.6.
So, given the scope below, can someone please explain what
4.4 changes are affecting me and what I need to do to overcome
them? Note that I have never had to do the machine changes
myself - in the past I simply waiting for Dave Pitts to do the
upgrade to the new version, and then with a working 370 code
generator I would make all the changes necessary for MVS.
This time I don't have a working code generator. With these
changes to force an executable, I can go:
xgcc --version
and it works, but when I attempt a compile (with -S), I get an
internal error in builtin line 0, which is presumably completely
meaningless because I haven't actually done the work yet.
Thanks. Paul.
Index: gcc4/config.sub
diff -c gcc4/config.sub:1.3 gcc4/config.sub:1.4
*** gcc4/config.sub:1.3 Mon Nov 23 12:58:07 2009
--- gcc4/config.sub Mon Nov 23 22:47:08 2009
***
*** 940,945
--- 940,948
rtpc | rtpc-*)
basic_machine=romp-ibm
;;
+ i370 | i370-*)
+ basic_machine=i370-ibm
+ ;;
s390 | s390-*)
basic_machine=s390-ibm
;;
Index: gcc4/gcc/config.gcc
diff -c gcc4/gcc/config.gcc:1.3 gcc4/gcc/config.gcc:1.4
*** gcc4/gcc/config.gcc:1.3 Mon Nov 23 12:58:07 2009
--- gcc4/gcc/config.gcc Mon Nov 23 22:46:56 2009
***
*** 358,363
--- 358,366
cpu_type=spu
need_64bit_hwint=yes
;;
+ i370*-*-*)
+ cpu_type=i370
+ ;;
s390*-*-*)
cpu_type=s390
need_64bit_hwint=yes
***
*** 1964,1969
--- 1967,1984
thread_file='aix'
extra_headers=altivec.h
;;
+ i370-*-mvspdp)
+ xm_defines='POSIX' # 'FATAL_EXIT_CODE=12'
+ xm_file="i370/xm-mvs.h"
+ tm_file="i370/mvspdp.h i370/i370.h"
+ tmake_file="i370/t-mvs i370/t-i370"
+ c_target_objs="i370-c.o"
+ cxx_target_objs="i370-c.o"
+ ;;
+ s390-*-linux*)
+ tm_file="s390/s390.h dbxelf.h elfos.h svr4.h linux.h s390/linux.h"
+ tmake_file="${tmake_file} t-dfprules s390/t-crtstuff s390/t-linux"
+ ;;
s390-*-linux*)
tm_file="s390/s390.h dbxelf.h elfos.h svr4.h linux.h s390/linux.h"
tmake_file="${tmake_file} t-dfprules s390/t-crtstuff s390/t-linux"
Index: gcc4/gcc/config/i370/i370-c.c
diff -c gcc4/gcc/config/i370/i370-c.c:1.5 gcc4/gcc/config/i370/i370-c.c:1.6
*** gcc4/gcc/config/i370/i370-c.c:1.5 Mon Nov 23 22:17:42 2009
--- gcc4/gcc/config/i370/i370-c.c Mon Nov 23 22:46:22 2009
***
*** 34,40
#ifdef TARGET_HLASM
! #define BAD(msgid) do { warning (msgid); return; } while (0)
/* #pragma map (name, alias) -
In this implementation both name and alias are required to be
--- 34,43
#ifdef TARGET_HLASM
! #define BAD(msgid) do { warning (0, msgid); return; } while (0)
!
! /* +++ c_lex has gone. however, we don't use it for anything important
anyway */
! #define c_lex(a)
/* #pragma map (name, alias) -
In this implementation both name and alias are required to be
***
*** 42,52
anyone clarify? */
void
! i370_pr_map (pfile)
! cpp_reader *pfile ATTRIBUTE_UNUSED;
{
tree name, alias, x;
if (c_lex (&x) != CPP_OPEN_PAREN)
BAD ("missing '(' after '#pragma map' - ignored");
--- 45,55
anyone clarify? */
void
! i370_pr_map (cpp_reader *pfile ATTRIBUTE_UNUSED)
{
tree name, alias, x;
+ #if 0
if (c_lex (&x) != CPP_OPEN_PAREN)
BAD ("missing '(' after '#pragma map' - ignored");
***
*** 63,70
BAD ("missing ')' for '#pragma map' - ignored");
if (c_lex (&x) != CPP_EOF)
! warning ("junk at end of '#pragma map'");
!
mvs_add_alias (IDENTIFIER_POINTER (name), TREE_STRING_POINTER (alias),
1);
}
--- 66,73
BAD ("missing ')' for '#pragma map' - ignored");
if (c_lex (&x) != CPP_EOF)
! warning (0, "junk at end of '#pragma map'");
! #endif
mvs_add_alias (IDENTIFIER_POINTER (name), TREE_STRING_POINTER (alias),
1);
}
***
*** 74,84
anyone clarify? */
void
! i370_pr_linkage (pfile)
! cpp_reader *pfile ATTRIBUTE_UNUSED;
{
tree name, mode, x;
if (c_lex (&x) != CPP_OPEN_PAREN)
BAD ("missing '(' after '#pragma linkage' - ignored");
--- 77,87
anyone clarify? */
void
! i370_pr_linkage (cpp_reader *pfile ATTRIBUTE_UNUSED)
{
tree name, mode, x;
+ #if 0
if (c_lex (&x) != CPP_OPEN_PAREN)
BAD ("missing '(' after '#pragma linkage' - ignored");
***
*** 95,102
BAD ("missing ')' for '#pragma linkage' - ignored");
if (c_lex (&x) != CPP_EOF)
! warning ("junk at end of '#pragma linkage'");
!
}
/* #pragma checkout (mode) -
--- 98,105
BAD ("missing ')' for '#pragma linkage' - ignored");
Re: GCC 4.5 is uncompilable
Dave Korn wrote: > If that doesn't fix it please let me know. The solution was correct, with binutils 2.20 the problem disappeared. There is another one, however on the snapshot 20091119: ../../gcc/lto-streamer-out.c: In function 'write_global_references': ../../gcc/lto-streamer-out.c:2201:7: error: passing argument 3 of 'lto_streamer_ cache_lookup' from incompatible pointer type ../../gcc/lto-streamer.h:790:13: note: expected 'int *' but argument is of type 'int32_t *' which is a source code bug: a local variable ref of type int32_t is passed by pointer to a function which takes int*. Don't know about trunk, as I just started building it. Best regards Piotr Wyderski
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
"Paul Edwards" writes:
> Index: gcc4/config.sub
> diff -c gcc4/config.sub:1.3 gcc4/config.sub:1.4
> *** gcc4/config.sub:1.3 Mon Nov 23 12:58:07 2009
> --- gcc4/config.sub Mon Nov 23 22:47:08 2009
You should send patches for config.{guess,sub} to
.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
Re: [cygwin-1.7] bootstrap failure: ../../gcc/gcc/config/i386/i386.c:24542:24: error: comparison between signed and unsigned integer expressions
2009/11/23 Christian Joensson: > Seems to me that http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00648.html > might cause this: > > /usr/local/src/trunk/objdir/./prev-gcc/xgcc > -B/usr/local/src/trunk/objdir/./prev-gcc/ > -B/usr/local/gnu/i686-pc-cygwin/bin/ > -B/usr/local/gnu/i686-pc-cygwin/bin/ > -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem > /usr/local/gnu/i686-pc-cygwin/include -isystem > /usr/local/gnu/i686-pc-cygwin/sys-include -c -g -O2 -gtoggle > -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes > -Wmissing-prototypes -Wmissing-format-attribute -pedantic > -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat > -fno-common > -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. > -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include > -Iyes/include -I../../gcc/gcc/../libdecnumber > -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber > -DCLOOG_PPL_BACKEND \ > ../../gcc/gcc/config/i386/i386.c -o i386.o > cc1: warnings being treated as errors > ../../gcc/gcc/config/i386/i386.c: In function 'avx_vpermilp_parallel': > ../../gcc/gcc/config/i386/i386.c:24542:24: error: comparison between signed > and > unsigned integer expressions > make[3]: *** [i386.o] Error 1 > make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' > make[2]: *** [all-stage2-gcc] Error 2 > make[2]: Leaving directory `/usr/local/src/trunk/objdir' > make[1]: *** [stage2-bubble] Error 2 > make[1]: Leaving directory `/usr/local/src/trunk/objdir' > > Windows XP Pro/SP3 cygwin Intel Core2 Duo t9...@2.80ghz system with packages: > > binutils 2.19.51-1 2.19.51.20090704 > bison 2.3-1 2.3 > cloog-ppl 0.15.3-1 > cygwin 1.7.0-65 > dejagnu 20021217-2 1.4.2.x > expect 20030128-1 5.26 > gcc4-ada 4.3.4-1 > gcc4-core 4.3.4-1 > gcc4-g++ 4.3.4-1 > gmp 4.3.1-3 > libcloog-devel 0.15.3-1 > libgmp-devel 4.3.1-3 > libmpc-devel 0.8-1 > libmpfr-devel 2.4.1-4 > libppl 0.10.2-1 > make 3.81-2 > mpclib 0.8-1 > mpfr 2.4.1-4 > ppl 0.10.2-1 > ppl-devel 0.10.2-1 > tcltk 20080420-1 8.4 > w32api 3.14-1 > > LAST_UPDATED: Mon Nov 23 06:25:08 UTC 2009 (revision 154431) > > This is on sorry, this was alreadey reported by H.J. Lu over on gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01215.html -- Cheers, /ChJ
Re: GCC 4.5 is uncompilable
Piotr Wyderski wrote: > Dave Korn wrote: > >> If that doesn't fix it please let me know. > > The solution was correct, with binutils 2.20 > the problem disappeared. There is another > one, however on the snapshot 20091119: > > ../../gcc/lto-streamer-out.c: In function 'write_global_references': > ../../gcc/lto-streamer-out.c:2201:7: error: passing argument 3 of > 'lto_streamer_ > cache_lookup' from incompatible pointer type > ../../gcc/lto-streamer.h:790:13: note: expected 'int *' but argument is of > type > 'int32_t *' > > which is a source code bug: a local variable ref of type > int32_t is passed by pointer to a function which takes int*. > Don't know about trunk, as I just started building it. One of the problems with snapshots; sometimes they capture the state of trunk while it has a bug extant. I have successfully compiled HEAD at r.154370 and r.154010 recently. cheers, DaveK
RE: Worth balancing the tree before scheduling?
David Edelsohn wrote: > On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton > wrote: > > From some simple experiments (see below), it appears as though GCC > aims > > to > > create a lop-sided tree when there are constants involved (func1 > below), > > but a balanced tree when there aren't (func2 below). > > > > Our assumption is that GCC likes having constants all near to each > other > > to > > aid with tree-based optimisations, but I'm fairly sure that, when it > > comes > > to scheduling, it would be better to have a balanced tree, so sched > has > > more > > choices about what to schedule next? > > I think this would depend on the target architecture and instruction > set: CISC vs RISC, many registers vs few registers, etc. I do not > believe that GCC intentionally is trying to optimize for either, but I > do not think there is a single, right answer. > Regardless of the architecture, I can't see how an unbalanced tree would ever be a good thing. With a balanced tree, you can still choose to process it in either direction (broad versus deep) - whichever is better for your architecture - but, as far as I can see (bearing in mind that I'm very new to GCC development!), a tall lop-sided tree gives few scheduling options due to all the extra dependencies. I guess I must be missing something? Regards, Ian
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
On 11/23/2009 11:32 AM, Paul Edwards wrote: So, given the scope below, can someone please explain what 4.4 changes are affecting me and what I need to do to overcome them? I think your best bet is to grep the changelogs for what has changes, and see what was done for other ports. Many target macros have become target hooks. Or, PREDICATE_CODES for example will require you to rewrite the r_or_s_operand and s_operand as "define_predicate" RTL; grep the ChangeLog for predicates.md. And so on. Paolo
Re: Worth balancing the tree before scheduling?
On Nov 23, 2009, at 10:17, Ian Bolton wrote: > Regardless of the architecture, I can't see how an unbalanced tree would > ever be a good thing. With a balanced tree, you can still choose to > process it in either direction (broad versus deep) - whichever is better > for your architecture - but, as far as I can see (bearing in mind that > I'm very new to GCC development!), a tall lop-sided tree gives few > scheduling options due to all the extra dependencies. I guess I must > be missing something? Yes, a lop-sided tree often needs less registers. For example, (((a+b)+c)+d)+e would only need 2 registers. Any more balanced tree would need at least one more. -Geert
internal compiler error: in simplify_subreg, at simplify-rtx.c:5138
Hi,
I'm using the latest gcc 4.5 to compile the latest linux kernel(rc8).
$ mips64el-unknown-linux-gnu-gcc --version
mips64el-unknown-linux-gnu-gcc (GCC) 4.5.0 20091123 (experimental)
and encountered this error:
$ make ARCH=mips CROSS_COMPILE=mips64el-unknown-linux-gnu- mm/rmap.o
CHK include/linux/version.h
CHK include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-mips
Checking missing-syscalls for N32
CALLscripts/checksyscalls.sh
Checking missing-syscalls for O32
CALLscripts/checksyscalls.sh
CALLscripts/checksyscalls.sh
CC mm/rmap.o
mm/rmap.c: In function 'try_to_unmap_one':
mm/rmap.c:860:1: internal compiler error: in simplify_subreg, at
simplify-rtx.c:5138
Please submit a full bug report,
I have tried to find the exact place which introduced this error and at
last found out this line of that file:
818 swp_entry_t entry = { .val = page_private(page) };
If I change that line to:
swp_entry_t entry = { .val = 1 };
the error will go away.
and I found that page_privete(page) is something like this:
include/linux/mm.h:
228 #define page_private(page) ((page)->private)
So, I moved that (page)->private to the above directly, and try it with:
swp_entry_t entry = { .val = ((page)->private) };
and
swp_entry_t entry = { .val = (page)->private };
and
swp_entry_t entry = { .val = page->private };
and even tried with:
swp_entry_t entry;
entry.val = page->private;
All of them failed, at last, I found the line of gcc:
5130 /* Simplify SUBREG:OUTERMODE(OP:INNERMODE, BYTE)
5131Return 0 if no simplifications are possible. */
5132 rtx
5133 simplify_subreg (enum machine_mode outermode, rtx op,
5134 enum machine_mode innermode, unsigned int byte)
5135 {
5136 /* Little bit of sanity checking. */
5137 gcc_assert (innermode != VOIDmode);
5138 gcc_assert (outermode != VOIDmode); --> This line.
5139 gcc_assert (innermode != BLKmode);
5140 gcc_assert (outermode != BLKmode);
any more information needed for the above problem?
Best Regards,
Wu Zhangjin
Re: Possible endless loop in lto-wrapper
2009/11/22 Leandro Nini :
> Hi,
>
> in gcc-4.5 lto-wrapper may end up in an endless loop in case of error:
>
> if for example a 'maybe_unlink_file' call from 'lto_wrapper_exit' fails it
> calls 'fatal_perror' which in turn calls 'lto_wrapper_exit' again causing
> an infinity of
>
> lto-wrapper: deleting LTRANS file /tmp/ccWjXUv8.lto.o: No such file or
> directory
>
> error messages on the console.
>
> I've solved this by substituting 'maybe_unlink_file' with
> 'unlink_if_ordinary'
> whithin the 'lto_wrapper_exit' function.
> Not sure if this is the best fix but hope it helps.
Thanks for finding the bug!
I think that we need something similar to what was done in the linker:
Avoid trying to start a new cleanup if we are already in one.
Leandro, can you try the attached patch?
Diego, OK if it works?
2009-11-23 Rafael Avila de Espindola
* lto-wrapper.c (lto_wrapper_exit): Don't try to delete files if
being called recursively.
>
> Best Regards,
> Leandro
> --
Cheers,
--
Rafael Ávila de Espíndola
Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c (revision 154452)
+++ gcc/lto-wrapper.c (working copy)
@@ -66,12 +66,20 @@
static void
lto_wrapper_exit (int status)
{
- if (ltrans_output_file)
-maybe_unlink_file (ltrans_output_file);
- if (flto_out)
-maybe_unlink_file (flto_out);
- if (args_name)
-maybe_unlink_file (args_name);
+ static bool cleanup_done = false;
+ if (!cleanup_done)
+{
+ /* Setting cleanup_done prevents an infinite loop if one of the
+ calls to maybe_unlink_file fails. */
+ cleanup_done = true;
+
+ if (ltrans_output_file)
+maybe_unlink_file (ltrans_output_file);
+ if (flto_out)
+maybe_unlink_file (flto_out);
+ if (args_name)
+maybe_unlink_file (args_name);
+}
exit (status);
}
Re: Possible endless loop in lto-wrapper
On Mon, Nov 23, 2009 at 13:59, Rafael Espindola wrote: > 2009-11-23 Rafael Avila de Espindola > > * lto-wrapper.c (lto_wrapper_exit): Don't try to delete files if > being called recursively. OK. Diego.
No .got section in ELF
The idea I got is about removing .got section in ELF format totally. Before we go, let's see the limitation on the idea 1) It must be deployed on aligned segment model, such as Linux, which cs.start = ds.start. 2) Currently, I only know how to do on x86 ELF. Here is a typical sample in PIC model (shared library) when library want to access its global data ... // Later code snippet template is used by gcc in almost all shared function // to imitate `mov %ip, %ebx'. call next: next: pop %ebx // << A. ... movl new_offset(%ebx), %eax // << B. load global variable foo to eax. ... .global foo // << C. OK!, to ld, offsetof(C - A) is const, and to gcc offsetof(B - A) is also const, so to aligned segment model, new_offset = offset(C - A) - offset(B - A), right? Here is the new workflow 1) Using new option, such as, new option `--segment-model=aligned' to trigger the feature. 2) Gcc creates a section (nogot) which stores data pair offsetof(B - A) and new_offset address for every function. 3) Ld reads nogot section and update new_offset according to above formular. 4) nogot section is discarded later. Constrast to traditional PIC code, we save an indirect memory load instruction and shrink memory fee by avoiding to load .got section into memory. And it seems it's fit with gcc4.5 link-time optimizer feature.
On strategies for function call instrumentation
Hi, I'm Derrick Coetzee and I'm a grad student working with Daniel
Wilkerson et al on the Hard Object project at UC Berkeley (see
http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-97.html). To
minimize implementation effort, we'd like to use gcc as the compiler
for our platform. The main trick is, to implement our custom stack
management, we need to inject a custom instruction before each
function call begins pushing its arguments, and insert a different
instruction right after each function call. We considered a couple
different ways to do this:
1. We have a C/C++ source-to-source translation framework. We could
translate each function call "f(a,b,c)" to something like "({ _asm {
... }; typeof(f(a,b,c)) result = f(a,b,c); _asm { ... }; result; })"
2. We could modify the code generation of gcc in a private fork.
Our main concern is that we need to be sure the instructions will be
executed at the right time, right before it starts pushing arguments
for the function and right after it returns, even in complex contexts
like nested function calls (f(g(a,b),c)). We're not sure how much gcc
will reorder these type of sequences, or what optimizations we might
be neglecting to consider. We're also not sure if we might be
overlooking superior approaches to the problem. Any advice is
appreciated.
--
Derrick Coetzee
University of California, Berkeley
