Re: [gofrontend-dev] Re: [PATCH 03/13] HACK! Allow the static chain to be set from C
On Fri, Oct 10, 2014 at 6:06 PM, Peter Collingbourne wrote: > On Fri, Oct 10, 2014 at 5:33 PM, 'Ian Lance Taylor' via gofrontend-dev > wrote: >> >> On Fri, Oct 10, 2014 at 1:42 PM, Richard Henderson wrote: >> > >> > This is awful syntax, and therefore contains no documentation. >> > But we'll need to be able to set the static chain on a few calls >> > within the Go runtime, so we need to expose this by some means. >> > >> > It currently looks like >> > >> > function(args...) __builtin_call_chain(pointer) >> > >> > because that was easy to parse. >> >> How crazy would it be to move __builtin_call_chain into the function >> arguments, as in >> function(a1, a2, __builtin_call_chain(pointer)) >> This __builtin_call_chain call would be removed from the argument list >> so type checking would only look at a1, a2. It would just set the >> static chain value. That at least puts the call_chain in the right >> place, which is a special kind of function argument. > > > Clang will need to be able to parse this syntax too, so let's not do > anything that diverges too much from the standard. > > Can we perhaps make this look like a new calling convention? So e.g. you > could do: > > (((void (__attribute__((chaincall)) *)(void *, int, int)))function)(pointer, > a1, a2); A colleague has suggested a perhaps nicer syntax: __builtin_call_chain(pointer, call) where call must be a call expression Peter
Re: [gofrontend-dev] Re: [PATCH 03/13] HACK! Allow the static chain to be set from C
On Mon, Oct 13, 2014 at 1:10 AM, Richard Biener wrote: > On Sat, Oct 11, 2014 at 6:23 AM, Richard Henderson wrote: >> On 10/10/2014 06:42 PM, Peter Collingbourne wrote: >>> A colleague has suggested a perhaps nicer syntax: >>> >>> __builtin_call_chain(pointer, call) where call must be a call expression >> >> I like this. >> >> Unlike the other suggestions, it doesn't mess with the parsing of the >> "regular" >> part of the function call. And, depending on what point the builtin is >> lowered >> and applied to the AST, it might not require any parsing changes at all. >> >> I'll have a look at this next week. Thanks. > > Does the frontend know that the call expects a static chain? The chain is not part of the function type, so no. Peter
[PATCH][JAVA] Build a correct tree for rewritten method invocations
The Java frontend currently produces an incorrectly typed tree if a method call is rewritten. Specifically, the callee operand is a NOP_EXPR casting the address of the target method to the original method type. This patch causes the NOP_EXPR cast to use the type of the target method instead. The bug is exposed by dragonegg which requires the callee type to be correct. libjava tested, x86_64-unknown-linux-gnu. 2011-08-02 Peter Collingbourne * expr.c (expand_invoke) Use the type of the method rewrite target. --- gcc/java/expr.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/java/expr.c b/gcc/java/expr.c index 4686f30..ec2d9b6 100644 --- a/gcc/java/expr.c +++ b/gcc/java/expr.c @@ -2544,12 +2544,12 @@ expand_invoke (int opcode, int method_ref_index, int nargs ATTRIBUTE_UNUSED) return; } - method_type = TREE_TYPE (method); - arg_list = pop_arguments (method_type); + arg_list = pop_arguments (TREE_TYPE (method)); flush_quick_stack (); maybe_rewrite_invocation (&method, &arg_list, &method_signature, &special); + method_type = TREE_TYPE (method); func = NULL_TREE; if (opcode == OPCODE_invokestatic) -- 1.7.5.3
Re: [RFC/RFT 0/3] Add compiler support for Control Flow Integrity
On Sun, Dec 18, 2022 at 10:06 PM Dan Li wrote: > > This series of patches is mainly used to support the control flow > integrity protection of the linux kernel [1], which is similar to > -fsanitize=kcfi in clang 16.0 [2,3]. > > I hope that this feature will also support user-mode CFI in the > future (at least for developers who can recompile the runtime), > so I use -fsanitize=cfi as a compilation option here. Please don't. The various CFI-related build flags are confusing enough without also having this inconsistency between Clang and GCC. Peter
