pagename:
* calling이 아니라 call도 ok?
* aka function_call ? invocation / invoke ?
* calling이 아니라 call도 ok?
* aka function_call ? invocation / invoke ?
나중에 api call ...etc 분리?
... chkout calling call invocation invoke ...Sub:
호출스택,call_stack =,call_stack .
시스템_호출,system_call =,system_call .
asynchronous call vs synchronous call
call_site =,call_site .
{
call site
https://en.wikipedia.org/wiki/Call_site
call site
call site
}
호출그래프,call_graph =호출그래프,call_graph =,call_graph . 호출그래프 call_graph (w)
{
call graph
호출스택,call_stack =,call_stack .
시스템_호출,system_call =,system_call .
asynchronous call vs synchronous call
call_site =,call_site .
{
call site
https://en.wikipedia.org/wiki/Call_site
call site
call site
}
호출그래프,call_graph =호출그래프,call_graph =,call_graph . 호출그래프 call_graph (w)
{
call graph
REL?
실행,execution
호출,call
software_visualization =,software_visualization . software_visualization { Software_visualization }
실행,execution
호출,call
software_visualization =,software_visualization . software_visualization { Software_visualization }
} // call graph call graph call graph call graph call graph
calling_convention =,calling_convention . calling_convention
{
호출규약 ? - 이 번역어 대세인 듯 하고 기타 가능한 번역은 호출관습 , 호출관례 ,
calling_convention =,calling_convention . calling_convention
{
호출규약 ? - 이 번역어 대세인 듯 하고 기타 가능한 번역은 호출관습 , 호출관례 ,
종류가 상당히 다양.
인자(parameter argument) 전달순서 : 왼쪽부터 or 오른쪽부터
스택프레임,stack_frame은 누가 정리할 것인가? caller or callee ?
등으로 여러 가지.
Rel
binary_interface
// 표현을 normalize하면 좋을텐데.. 혹시 call by value 는 명사구, call-by-value 는 형용사구 ?? 아님 근거없는생각임?
binary_interface
// 표현을 normalize하면 좋을텐데.. 혹시 call by value 는 명사구, call-by-value 는 형용사구 ?? 아님 근거없는생각임?
call_by_value
call-by-value (CBV)
call-by-push-value CBPV ?
call-by-value (CBV)
fine-grain call-by-value (FGCBV)
call_by_push_valuecall-by-push-value CBPV ?
tail_call = https://en.wiktionary.org/wiki/tail_call "A function call that is itself the last instruction in a function."
Tail_call = https://en.wikipedia.org/wiki/Tail_call
이런 성질을 가진 subroutine을 tail recursive라고 한다.
tail call은 call stack에 stack frame을 추가하지 않게 만들어질 수 있다 - 즉 더 효율적인 코드 생성이 가능해짐}
call gate
call_gate =,call_gate . call_gate
privilege_escalation 맞나?
call_gate x 2023-08-20
https://ko.wikipedia.org/wiki/콜_게이트
https://en.wikipedia.org/wiki/Call_gate_(Intel)
https://en.wikipedia.org/wiki/Call_gate_(Intel)
call_gate =,call_gate . call_gate
privilege_escalation 맞나?
call_gate x 2023-08-20
https://ko.wikipedia.org/wiki/콜_게이트
https://en.wikipedia.org/wiki/Call_gate_(Intel)
https://en.wikipedia.org/wiki/Call_gate_(Intel)
.... ADDHERE
MKLINK
API
ABI,application_binary_interface
라이브러리,library
메소드,method
펑션,function
주소,address esp 메모리주소,memory_address
API
ABI,application_binary_interface
라이브러리,library
메소드,method
펑션,function
함수를 정의,definition한 다음엔 (i.e. function_definition 이 끝나면) 함수를 호출할 수 있음.
subroutine or routine 서브루틴 루틴주소,address esp 메모리주소,memory_address
호출의 대상은? QQQ
이벤트,event - 이벤트를 발생시킨다 = 이벤트를 호출한다 - 어떤 func/method를 call함으로써?일반적으로는 API 라이브러리,library ...?
일단 알아보기 전에 생각나는 건
distributed가 아닌 상황에서는 같은 machine의 function method subroutine procedure ...
환경에 따라
일단 알아보기 전에 생각나는 건
distributed가 아닌 상황에서는 같은 machine의 function method subroutine procedure ...
환경에 따라
반드시 어떤 이름지어진(named) / 식별자,identifier가 있는 / ... 게 아닌 임의의 메모리주소,memory_address를 호출하는 것도 가능하고 (위험)
그것이 실행환경? 에 의해 막힌 경우가 대부분일테고
distributed 상황에서는 RPC RMI 같은 - or RESTful API , web api , ... 뭐 이런 - 이때는 remote machine i.e. 서버,server ? 항상 웹서버,web_server는 아니겠고.. API server api provider ? 스텁,stub그것이 실행환경? 에 의해 막힌 경우가 대부분일테고