Displaying 8 results from an estimated 8 matches for "_pointer_".
2008 Nov 12
2
[LLVMdev] RefineAbstractType
...t;
> %t1 = type opaque
> %t2 = type void(%t1*)
>
> and you refine t1 -> t2, it should work.
I'm not sure it will. %t1* is the "contained" type inside the FunctionType.
RefineAbstractTypes expects the OldType (%t1 in this case) to be in the
contained type set. Since a _pointer_ to %t1 is in the contained set, it
doesn't see it.
-Dave
2008 Nov 13
0
[LLVMdev] RefineAbstractType
...void(%t1*)
>>
>> and you refine t1 -> t2, it should work.
>
> I'm not sure it will. %t1* is the "contained" type inside the
> FunctionType.
> RefineAbstractTypes expects the OldType (%t1 in this case) to be in
> the
> contained type set. Since a _pointer_ to %t1 is in the contained
> set, it
> doesn't see it.
How is this any different than the struct case of {\2*} ?
-Chris
2008 Nov 13
3
[LLVMdev] RefineAbstractType
...gt; and you refine t1 -> t2, it should work.
> >
> > I'm not sure it will. %t1* is the "contained" type inside the
> > FunctionType.
> > RefineAbstractTypes expects the OldType (%t1 in this case) to be in
> > the
> > contained type set. Since a _pointer_ to %t1 is in the contained
> > set, it
> > doesn't see it.
>
> How is this any different than the struct case of {\2*} ?
I don't know. All I know is when I called %t2->refineAbstractType(%t1, %t2)
it didn't work. That was the pointer of the question. RefineAbstr...
2007 Aug 09
9
Is DTrace Vulnerable?
There is a Slashdot discussion today titled "Cambridge Researcher Breaks
OpenBSD Systrace". Slashdot anonymous member has a comment "Even Sun''s
Dtrace might be vulnerable." I don''t think it is. Comments?
Exploiting Concurrency Vulnerabilities in System Call Wrappers
http://www.watson.org/~robert/2007woot/2007usenixwoot-exploitingconcurrency.pdf
Abstract
2008 Nov 13
0
[LLVMdev] RefineAbstractType
...t1 -> t2, it should work.
>>>
>>> I'm not sure it will. %t1* is the "contained" type inside the
>>> FunctionType.
>>> RefineAbstractTypes expects the OldType (%t1 in this case) to be in
>>> the
>>> contained type set. Since a _pointer_ to %t1 is in the contained
>>> set, it
>>> doesn't see it.
>>
>> How is this any different than the struct case of {\2*} ?
>
> I don't know. All I know is when I called %t2-
> >refineAbstractType(%t1, %t2)
> it didn't work. That was the po...
2008 Nov 13
2
[LLVMdev] RefineAbstractType
...> >>>
> >>> I'm not sure it will. %t1* is the "contained" type inside the
> >>> FunctionType.
> >>> RefineAbstractTypes expects the OldType (%t1 in this case) to be in
> >>> the
> >>> contained type set. Since a _pointer_ to %t1 is in the contained
> >>> set, it
> >>> doesn't see it.
> >>
> >> How is this any different than the struct case of {\2*} ?
> >
> > I don't know. All I know is when I called %t2-
> >
> > >refineAbstractType(%t1, %t...
2008 Nov 12
0
[LLVMdev] RefineAbstractType
On Nov 12, 2008, at 2:59 PM, David Greene wrote:
> Is there some reason that RefineAbstractType doesn't recurse down
> DerivedTypes
> and further resolve abstract types?
Because that would resolve two different types. RefineAbstractType
just refines the one type you request, and further uniques types based
on it.
In fact, I strongly suspect that RefineAbstractType
2008 Nov 12
2
[LLVMdev] RefineAbstractType
Is there some reason that RefineAbstractType doesn't recurse down DerivedTypes
and further resolve abstract types?
In Fortran it is possible to have a routine that takes a function pointer to a
routine with the same signature. This is not possible to express in C/C++.
I'm not sure it's possible to express in LLVM either without using varargs
(opinions welcome).
In a simpler C++