처음, 이전, 다음, 마지막 절로 가기, 목차.
This section describes some of the routines used in the C++ front-end.
will get the related binfo.
Supposedly (according to Tiemann) most of the breadth first searching
done, like in
원문시작
Limitations of g++
Routines
build_vtable and prepare_fresh_vtable is used only within
the `cp-class.c' file, and only in finish_struct and
modify_vtable_entries.
build_vtable, prepare_fresh_vtable, and
finish_struct are the only routines that set DECL_VPARENT.
finish_struct can steal the virtual function table from parents,
this prohibits related_vslot from working. When finish_struct steals,
we know that
get_binfo (DECL_FIELD_CONTEXT (CLASSTYPE_VFIELD (t)), t, 0)
layout_basetypes does something with the VIRTUALS.
get_base_distance and in get_binfo was not
because of any design decision. I have since found out the at least one
part of the compiler needs the notion of depth first binfo searching, I
am going to try and convert the whole thing, it should just work. The
term left-most refers to the depth first left-most node. It uses
MAIN_VARIANT == type as the condition to get left-most, because
the things that have BINFO_OFFSETs of zero are shared and will
have themselves as their own MAIN_VARIANTs. The non-shared right
ones, are copies of the left-most one, hence if it is its own
MAIN_VARIANT, we know it IS a left-most one, if it is not, it is
a non-left-most one.
get_base_distance's path and distance matters in its use in:
prepare_fresh_vtable (the code is probably wrong)
init_vfields Depends upon distance probably in a safe way,
build_offset_ref might use partial paths to do further lookups,
hack_identifier is probably not properly checking access.
get_first_matching_virtual probably should check for
get_base_distance returning -2.
resolve_offset_ref should be called in a more deterministic
manner. Right now, it is called in some random contexts, like for
arguments at build_method_call time, default_conversion
time, convert_arguments time, build_unary_op time,
build_c_cast time, build_modify_expr time,
convert_for_assignment time, and
convert_for_initialization time.
But, there are still more contexts it needs to be called in, one was the
ever simple:
if (obj.*pmi != 7)
...
Seems that the problems were due to the fact that TREE_TYPE of
the OFFSET_REF was not a OFFSET_TYPE, but rather the type
of the referent (like INTEGER_TYPE). This problem was fixed by
changing default_conversion to check TREE_CODE (x),
instead of only checking TREE_CODE (TREE_TYPE (x)) to see if it
was OFFSET_TYPE.
Implementation Specifics
current_member_init_list contains the list of
mem-initializers specified in a constructor declaration. For example:
foo::foo() : a(1), b(2) {}
will initialize `a' with 1 and `b' with 2.
expand_member_init places each initialization (a with 1) on the
global list. Then, when the fndecl is being processed,
emit_base_init runs down the list, initializing them. It used to
be the case that g++ first ran down current_member_init_list,
then ran down the list of members initializing the ones that weren't
explicitly initialized. Things were rewritten to perform the
initializations in order of declaration in the class. So, for the above
example, `a' and `b' will be initialized in the order that
they were declared:
class foo { public: int b; int a; foo (); };
Thus, `b' will be initialized with 2 first, then `a' will be
initialized with 1, regardless of how they're listed in the mem-initializer.
explicit on a constructor is used by grokdeclarator
to set the field DECL_NONCONVERTING_P. That value is used by
build_method_call and build_user_type_conversion_1 to decide
if a particular constructor should be used as a candidate for conversions.
Glossary
is_normal depends upon this.
FIELD_DECLs that are pointer types that point to
vtables. See also vtable and vfield.
원문끝
본 절은 C++ front-end에서 종종 사용되는 몇가지 루틴(routine)을 기술한다.
build_vtable과 prepare_fresh_vtable는 `cp-class.c' 파일내에서만 사용된다. 그리고 finish_struct과
modify_vtable_entries에서만 사용된다.
build_vtable, prepare_fresh_vtable,
finish_struct는 DECL_VPARENT를 설정하는 유일한 루틴이다.
finish_struct는 상위로부터 가상함수표(virtual function table)를 훔쳐올 수 있다. 이것은 related_vslot이 동작하는 것을 방지한다. finish_struct가 표를 훔쳐올 때,
get_binfo (DECL_FIELD_CONTEXT (CLASSTYPE_VFIELD (t)), t, 0)
가 관련 binfo를 얻는다는 것을 안다.
layout_basetypes는 VIRTUALS로 뭔가를 한다.
Supposedly (according to Tiemann) most of the breadth first searching
done, like in get_base_distance and in get_binfo was not
because of any design decision. I have since found out the at least one
part of the compiler needs the notion of depth first binfo searching, I
am going to try and convert the whole thing, it should just work. The
term left-most refers to the depth first left-most node. It uses
MAIN_VARIANT == type as the condition to get left-most, because
the things that have BINFO_OFFSETs of zero are shared and will
have themselves as their own MAIN_VARIANTs. The non-shared right
ones, are copies of the left-most one, hence if it is its own
MAIN_VARIANT, we know it IS a left-most one, if it is not, it is
a non-left-most one.
다음과 같은 사용에서 get_base_distance의 경로와 거리 문제:
prepare_fresh_vtable (코드가 어쩌면 틀린다)
init_vfields는 안전한 방법으로 어쩌면 거리에 의존한다. build_offset_ref는 훨씬 더 많이 룩업(lookup)하기위해 부분 경로(partial path)를 사용할지도 모른다. hack_identifier는 아마 접속을 적절히 검사하지 못할것이다.
get_first_matching_virtual은 -2를 반환하는 get_base_distance에 대해 어쩌면 검사해야한다.
resolve_offset_ref은 좀더 결정적인 방법으로 불려져야 한다. 바로 그것은 build_method_call 시간, default_conversion 시간, convert_arguments 시간, build_unary_op 시간, build_c_cast 시간, build_modify_expr 시간, convert_for_assignment 시간, convert_for_initialization 시간에서 인자에 대한 것처럼, 몇가지 임의 문맥(random context)에서 불려진다. 그러나 여전히 불려져야하는 더 많은 문맥이 있다. 한가지는 여전히 간단했었다:
if (obj.*pmi != 7)
...
문제점들이 OFFSET_REF의 TREE_TYPE이 OFFSET_TYPE이 아니고, 오히려 (INTEGER_TYPE과 같은) 지시(referent) 형이라는 사실에 기인하는 것처럼 보인다.
이 문제는 OFFSET_TYPE인지를 보기위한 TREE_CODE (TREE_TYPE (x))만 오직 검사하는대신, OFFSET_CODE (x)를 검사하기위한 default_conversion 을 변경함으로써 고쳐졌다.
current_member_init_list는 생성자 선언에 지정된 mem-initializer의 목록을 포함한다. 예를 들면:
foo::foo() : a(1), b(2) {}
이것은 `a'를 1로, `b'를 2로 초기화 할 것이다. expand_member_init는 전역 목록상에 각 초기값(a를 1로)을 위치시킨다.
그런다음 fndecl이 처리되고 있을때, emit_base_init 는 그것들을 초기화하면서 목록을 훑어 내려간다.
g++은 우선 current_member_init_list를 훑어 내려가는 경우에 사용된다. 그다음 명확히 초기화되지 않은 것들을 초기화할 멤버의 목록을 훑어 내려간다.
그것들은 클래스에서 선언을 위해 초기화를 수행하도록 다시 써져야 한다. 그래서 위의 예에서, `a'와 `b'는 그들이 선언되기 위해서 초기화될 것이다:
class foo { public: int b; int a; foo (); };
이렇듯 `b'는 우선 2로 초기화될 것이다. 그리고나서 `a'가 1로 초기화될 것이다. 그것들이 mem-initializer에 어떻게 적혀있던간에 말이다.
explicit의 사용은 필드 DECL_NONCONVERTING_P를 설정하기 위해 grokdeclarator에 의해 사용된다.
그 값은 특별한 생성자가 변환을 위한 지원자로써 사용되야하는지를 결정하기위해 build_method_call과 build_user_type_conversion_1에 의해 사용된다.
is_normal은 이에 달려있다.
FIELD_DECL이다. vtable와 vfield를 보라.
This section describes some of the macros used on trees. The list should be alphabetical. Eventually all macros should be documented here.
BINFO_BASETYPES
BINFO_INHERITANCE_CHAIN
Z ZbY least derived | Y YbX | X Xb most derived TYPE_BINFO (X) == Xb BINFO_INHERITANCE_CHAIN (Xb) == YbX BINFO_INHERITANCE_CHAIN (Yb) == ZbY BINFO_INHERITANCE_CHAIN (Zb) == 0Not sure is the above is really true, get_base_distance has is point towards the most derived type, opposite from above. Set by build_vbase_path, recursive_bounded_basetype_p, get_base_distance, lookup_field, lookup_fnfields, and reverse_path. What things can this be used on: TREE_VECs that are binfos
BINFO_OFFSET
BINFO_VIRTUALS
BINFO_VTABLE
BLOCK_SUPERCONTEXT
CLASSTYPE_TAGS
CLASSTYPE_METHOD_VEC
CLASSTYPE_VFIELD
DECL_CLASS_CONTEXT
struct A
{
virtual int f ();
};
struct B : A
{
int f ();
};
DECL_CONTEXT (A::f) == A
DECL_CLASS_CONTEXT (A::f) == A
DECL_CONTEXT (B::f) == A
DECL_CLASS_CONTEXT (B::f) == B
Has values of:
RECORD_TYPEs, or UNION_TYPEs
What things can this be used on:
TYPE_DECLs, _DECLs
DECL_CONTEXT
VAR_DECLs that are virtual function tables _DECLs
DECL_FIELD_CONTEXT
FIELD_DECLs that are virtual function pointers FIELD_DECLs
DECL_NAME
0 for things that don't have names IDENTIFIER_NODEs for TYPE_DECLs
DECL_IGNORED_P
DECL_VIRTUAL_P
DECL_VPARENT
DECL_FCONTEXT
DECL_REFERENCE_SLOT
DECL_VINDEX
DECL_SOURCE_FILE
DECL_SOURCE_LINE
0 for an undefined label 0 for TYPE_DECLs that are internally generated 0 for FUNCTION_DECLs for functions generated by the compiler (not yet, but should be) 0 for "magic" arguments to functions, that the user has no control over
TREE_USED
TREE_ADDRESSABLE
TREE_COMPLEXITY
TREE_HAS_CONSTRUCTOR
TREE_PRIVATE
TREE_PROTECTED
TYPE_BINFO
TYPE_BINFO_BASETYPES
TYPE_BINFO_VIRTUALS
TYPE_BINFO_VTABLE
TYPE_NAME
0 for things that don't have names.
should be IDENTIFIER_NODE for RECORD_TYPEs UNION_TYPEs and
ENUM_TYPEs.
TYPE_DECL for RECORD_TYPEs, UNION_TYPEs and ENUM_TYPEs, but
shouldn't be.
TYPE_DECL for typedefs, unsure why.
What things can one use this on:
TYPE_DECLs RECORD_TYPEs UNION_TYPEs ENUM_TYPEsHistory: It currently points to the TYPE_DECL for RECORD_TYPEs, UNION_TYPEs and ENUM_TYPEs, but it should be history soon.
TYPE_METHODS
CLASSTYPE_METHOD_VEC. Chained together with
TREE_CHAIN. `dbxout.c' uses this to get at the methods of a
class.
TYPE_DECL
typedef int foo; is
seen.
DECL_SOURCE_LINE identifies what source line number in the
source file the declaration was found at. A value of 0
indicates that this TYPE_DECL is just an internal binding layer
marker, and does not correspond to a user supplied typedef.
DECL_SOURCE_FILE
TYPE_FIELDS
TREE_CHAIN) of member types of a class. The
list can contain TYPE_DECLs, but there can also be other things
in the list apparently. See also CLASSTYPE_TAGS.
TYPE_VIRTUAL_P
FIELD_DECL or a VAR_DECL, indicates it is
a virtual function table or a pointer to one. When used on a
FUNCTION_DECL, indicates that it is a virtual function. When
used on an IDENTIFIER_NODE, indicates that a function with this
same name exists and has been declared virtual.
When used on types, it indicates that the type has virtual functions, or
is derived from one that does.
Not sure if the above about virtual function tables is still true. See
also info on DECL_VIRTUAL_P.
What things can this be used on:
FIELD_DECLs, VAR_DECLs, FUNCTION_DECLs, IDENTIFIER_NODEs
VF_BASETYPE_VALUE
finish_base_struct time.
What things can this be used on:
TREE_LISTs that are vfields
History:
This field was used to determine if a virtual function table's
slot should be filled in with a certain virtual function, by
checking to see if the type returned by VF_BASETYPE_VALUE was a
parent of the context in which the old virtual function existed.
This incorrectly assumes that a given type _could_ not appear as
a parent twice in a given inheritance lattice. For single
inheritance, this would in fact work, because a type could not
possibly appear more than once in an inheritance lattice, but
with multiple inheritance, a type can appear more than once.
VF_BINFO_VALUE
TREE_VIA_VIRTUAL
on result to find out if it is a virtual base class. Related to the
binfo found by
get_binfo (VF_BASETYPE_VALUE (vfield), t, 0)where `t' is the type that has the given vfield.
get_binfo (VF_BASETYPE_VALUE (vfield), t, 0)will return the binfo for the given vfield. May or may not be set at
modify_vtable_entries time. Set at
finish_base_struct time.
What things can this be used on:
TREE_LISTs that are vfields
VF_DERIVED_VALUE
finish_base_struct time.
What things can this be used on:
TREE_LISTs that are vfields
VF_NORMAL_VALUE
finish_base_struct time.
What things can this be used on:
TREE_LISTs that are vfields
WRITABLE_VTABLES
본 절은 트리(tree)에서 사용된 몇가지 매크로를 기술한다. 목록은 알파벳순이어야 한다. 결국 모든 매크로는 여기에 문서화되어야 한다.
BINFO_BASETYPES
BINFO_INHERITANCE_CHAIN
Z ZbY least derived | Y YbX | X Xb most derived TYPE_BINFO (X) == Xb BINFO_INHERITANCE_CHAIN (Xb) == YbX BINFO_INHERITANCE_CHAIN (Yb) == ZbY BINFO_INHERITANCE_CHAIN (Zb) == 0위의 것이 정말 사실인지는 확실치 않다. get_base_distance는 위와 반대로 가장 만힝 파생된 형(most derived type)쪽을 가르킨다. build_vbase_path, recursive_bounded_basetype_p, get_base_distance, lookup_field, lookup_fnfields, reverse_path 를 모아두어라. 이것은 어떤 것들에게 사용될 수 있는가: binfo인 TREE_VEC
BINFO_OFFSET
BINFO_VIRTUALS
BINFO_VTABLE
BLOCK_SUPERCONTEXT
CLASSTYPE_TAGS
CLASSTYPE_METHOD_VEC
CLASSTYPE_VFIELD
DECL_CLASS_CONTEXT
struct A
{
virtual int f ();
};
struct B : A
{
int f ();
};
DECL_CONTEXT (A::f) == A
DECL_CLASS_CONTEXT (A::f) == A
DECL_CONTEXT (B::f) == A
DECL_CLASS_CONTEXT (B::f) == B
다음의 값을 가진다:
RECORD_TYPE 또는 UNION_TYPE
이것은 어떤 것들에게 사용될 수 있는가:
TYPE_DECL, _DECL
DECL_CONTEXT
가상 함수표인 VAR_DECL _DECL
DECL_FIELD_CONTEXT
가상 함수포인터인 FIELD_DECL FIELD_DECL
DECL_NAME
이름을 가지지 않는 것에 대해 0 TYPE_DECL에 대해 IDENTIFIER_NODE
DECL_IGNORED_P
DECL_VIRTUAL_P
DECL_VPARENT
DECL_FCONTEXT
DECL_REFERENCE_SLOT
DECL_VINDEX
DECL_SOURCE_FILE
DECL_SOURCE_LINE
정의 되지 않은 라벨(label)에 대해 0
내부적으로 생성된 TYPE_DECL에 대해 0
컴파일러에 의해 생성된 함수에 대한 FUNCTION_DECL에 대해 0
(아직 아니다, 그러나 있어야 한다.)
사용자가 관리할 수 없는 함수에 대한 인자 "magic"에 대해 0
TREE_USED
TREE_ADDRESSABLE
TREE_COMPLEXITY
TREE_HAS_CONSTRUCTOR
TREE_PRIVATE
TREE_PROTECTED
TYPE_BINFO
TYPE_BINFO_BASETYPES
TYPE_BINFO_VIRTUALS
TYPE_BINFO_VTABLE
TYPE_NAME
이름을 가지지 않는 것에 대해 0. RECORD_TYPE, UNION_TYPE, ENUM_TYPE에 대해 IDENTIFIER_NODE이어야 하지만, RECORD_TYPE, UNION_TYPE, ENUM_TYPE에 대해 TYPE_DECL이어서는 안된다. typedefs에 대해 TYPE_DECL, 왜 그런지 확실치 않다.이것은 어떤 것들에게 사용될 수 있는가:
TYPE_DECL RECORD_TYPE UNION_TYPE ENUM_TYPEHistory: 그것은 일반적으로 RECORD_TYPE에 대한 TYPE_DECL, UNION_TYPE, ENUM_TYPE를 지시한다. 그러나 곧 history가 된다.
TYPE_METHODS
CLASSTYPE_METHOD_VEC에 대한 동의어. TREE_CHAIN과 함께 묶여있다. `dbxout.c'는 클래스의 메서드를 얻기위해 이것을 이용한다.
TYPE_DECL
typedef int foo;가 보여질 때, foo가 DECL_NAME 슬롯에서 발견된다.
DECL_SOURCE_LINE는 선언이 발견된 원시 파일내에서 어떤 source line number와 동일하다.
0의 값은 이 TYPE_DECL이 단지 내부의 binding layer marker일 뿐이라는 것을 가르켜준다. 그리고 user supplied typedef와 일치하지 않는다.
DECL_SOURCE_FILE
TYPE_FIELDS
TREE_CHAIN을 통한) 링크 목록. 목록은 TYPE_DECL을 포함할 수 있다. 그러나 분명히 목록에 다른 것들이 있을 수도 있다. 또한 CLASSTYPE_TAGS를 보라.
TYPE_VIRTUAL_P
FIELD_DECL이나 VAR_DECL상에서 사용된 플래그.
그것이 가상 함수표라는 것을 가르키거나 포인터임을 가르킨다.
FUNCTION_DECL에서 사용될 때, 그것이 가상 함수라는 것을 가르킨다.
IDENTIFIER_NODE에서 사용될 때, 같은 이름을 가진 함수가 존재하고 virtual로 선언되었음을 가르킨다.
형에 사용될 때, 형(type)이 가상 함수를 가진다는 것을 가르킨다.
또는 그렇게 행하는 것으로 부터 파생된다. 위의 가상 함수표에 대한 것은 아직까지 사실인지 아닌지확실치 않다.
또한 DECL_VIRTUAL_P상의 info를 보라.
이것은 어떤 것들에게 사용될 수 있는가:
FIELD_DECL, VAR_DECL, FUNCTION_DECL, IDENTIFIER_NODE
VF_BASETYPE_VALUE
finish_base_struct 시간에 설정한다.
이것은 어떤 것들에게 사용될 수 있는가:
vfield인 TREE_LIST
Histroy:
이 필드는 VF_BASETYPE_VALUE에 의해 반환된 형이 예전 가상 함수가 존재했던 문맥(context)의 부모였는지를 알아보기 위해 검사함으로써, 가상 함수표의 슬롯이 어떤 가상 함수로 채워져야 할지 아닐지를 결정하는데 사용되곤 했다. 이것은 주어진 형 _could_ 가 주어진 상속 lattice에서 부모로써 두번보이지 않는다라고 부정확하게 가정한다.
단독 상속에 대해 이것은 사실상 동작할 것이다. 왜냐하면 형은 상속 lattice에서 아마도 한번 이상 보일 수 없기 때문이다. 그러나 다중 상속을 가진 형은 한번이상 보일 수 있다.
VF_BINFO_VALUE
TREE_VIA_VIRTUAL을 사용할 수 있다.
binfo에 관한 것은 다음에 의해 발견된다.
get_binfo (VF_BASETYPE_VALUE (vfield), t, 0)여기서 `t'는 주어진 vfield를 가진 형이다.
get_binfo (VF_BASETYPE_VALUE (vfield), t, 0)이것은 주어진 vfield에 대해 binfo를 반환할 것이다.
modify_vtable_entries 시간에 설정한다. finish_base_struct 시간에 설정한다.
이것은 어떤 것들에게 사용될 수 있는가:
vfield인 TREE_LIST
VF_DERIVED_VALUE
finish_base_struct 시간에 설정한다.
이것은 어떤 것들에게 사용될 수 있는가:
vfield인 TREE_LIST
VF_NORMAL_VALUE
finish_base_struct 시간에 설정한다.
이것은 어떤 것들에게 사용될 수 있는가:
vfield인 TREE_LIST
WRITABLE_VTABLES
Whenever seemingly normal code fails with errors like
syntax error at `\{', it's highly likely that grokdeclarator is
returning a NULL_TREE for whatever reason.
It should never be that case that trees are modified in-place by the back-end, unless it is guaranteed that the semantics are the same no matter how shared the tree structure is. `fold-const.c' still has some cases where this is not true, but rms hypothesizes that this will never be a problem.
A template is represented by a TEMPLATE_DECL. The specific
fields used are:
DECL_TEMPLATE_RESULT
DECL_TEMPLATE_PARMS
The generic decl is parsed as much like any other decl as possible, given the parameterization. The template decl is not built up until the generic decl has been completed. For template classes, a template decl is generated for each member function and static data member, as well.
Template members of template classes are represented by a TEMPLATE_DECL for the class' parameters around another TEMPLATE_DECL for the member's parameters.
All declarations that are instantiations or specializations of templates refer to their template and parameters through DECL_TEMPLATE_INFO.
How should I handle parsing member functions with the proper param decls? Set them up again or try to use the same ones? Currently we do the former. We can probably do this without any extra machinery in store_pending_inline, by deducing the parameters from the decl in do_pending_inlines. PRE_PARSED_TEMPLATE_DECL?
If a base is a parm, we can't check anything about it. If a base is not a parm, we need to check it for name binding. Do finish_base_struct if no bases are parameterized (only if none, including indirect, are parms). Nah, don't bother trying to do any of this until instantiation -- we only need to do name binding in advance.
Always set up method vec and fields, inc. synthesized methods. Really? We can't know the types of the copy folks, or whether we need a destructor, or can have a default ctor, until we know our bases and fields. Otherwise, we can assume and fix ourselves later. Hopefully.
The function compute_access returns one of three values:
access_public
access_protected
access_private
DECL_ACCESS is used for access declarations; alter_access creates a list of types and accesses for a given decl.
Formerly, DECL_{PUBLIC,PROTECTED,PRIVATE} corresponded to the return codes of compute_access and were used as a cache for compute_access. Now they are not used at all.
TREE_PROTECTED and TREE_PRIVATE are used to record the access levels granted by the containing class. BEWARE: TREE_PUBLIC means something completely unrelated to access control!
The C++ front-end uses a call-back mechanism to allow functions to print
out reasonable strings for types and functions without putting extra
logic in the functions where errors are found. The interface is through
the cp_error function (or cp_warning, etc.). The
syntax is exactly like that of error, except that a few more
conversions are supported:
There is some overlap between these; for instance, any of the node
options can be used for printing an identifier (though only %D
tries to decipher function names).
For a more verbose message (class foo as opposed to just foo,
including the return type for functions), use %#c.
To have the line number on the error message indicate the line of the
DECL, use cp_error_at and its ilk; to indicate which argument you want,
use %+D, or it will default to the first.
Some comments on the parser:
The after_type_declarator / notype_declarator hack is
necessary in order to allow redeclarations of TYPENAMEs, for
instance
typedef int foo;
class A {
char *foo;
};
In the above, the first foo is parsed as a notype_declarator,
and the second as a after_type_declarator.
Ambiguities:
There are currently four reduce/reduce ambiguities in the parser. They are:
1) Between template_parm and
named_class_head_sans_basetype, for the tokens aggr
identifier. This situation occurs in code looking like
template <class T> class A { };
It is ambiguous whether class T should be parsed as the
declaration of a template type parameter named T or an unnamed
constant parameter of type class T. Section 14.6, paragraph 3 of
the January '94 working paper states that the first interpretation is
the correct one. This ambiguity results in two reduce/reduce conflicts.
2) Between primary and type_id for code like `int()'
in places where both can be accepted, such as the argument to
sizeof. Section 8.1 of the pre-San Diego working paper specifies
that these ambiguous constructs will be interpreted as typenames.
This ambiguity results in six reduce/reduce conflicts between
`absdcl' and `functional_cast'.
3) Between functional_cast and
complex_direct_notype_declarator, for various token strings.
This situation occurs in code looking like
int (*a);
This code is ambiguous; it could be a declaration of the variable `a' as a pointer to `int', or it could be a functional cast of `*a' to `int'. Section 6.8 specifies that the former interpretation is correct. This ambiguity results in 7 reduce/reduce conflicts. Another aspect of this ambiguity is code like 'int (x[2]);', which is resolved at the '[' and accounts for 6 reduce/reduce conflicts between `direct_notype_declarator' and `primary'/`overqualified_id'. Finally, there are 4 r/r conflicts between `expr_or_declarator' and `primary' over code like 'int (a);', which could probably be resolved but would also probably be more trouble than it's worth. In all, this situation accounts for 17 conflicts. Ack!
The second case above is responsible for the failure to parse 'LinppFile ppfile (String (argv[1]), &outs, argc, argv);' (from Rogue Wave Math.h++) as an object declaration, and must be fixed so that it does not resolve until later.
4) Indirectly between after_type_declarator and parm, for
type names. This occurs in (as one example) code like
typedef int foo, bar;
class A {
foo (bar);
};
What is bar inside the class definition? We currently interpret
it as a parm, as does Cfront, but IBM xlC interprets it as an
after_type_declarator. I believe that xlC is correct, in light
of 7.1p2, which says "The longest sequence of decl-specifiers that
could possibly be a type name is taken as the decl-specifier-seq of
a declaration." However, it seems clear that this rule must be
violated in the case of constructors. This ambiguity accounts for 8
conflicts.
Unlike the others, this ambiguity is not recognized by the Working Paper.
겉으로 보기에는 일반적인 코드가 syntax error at `\{'와 같은 오류들로 실패할때마다, grokdeclarator는 이유가 무엇이든지 이에 대해 NULL_TREE를 반환하는것 같다.
It should never be that case that trees are modified in-place by the back-end, unless it is guaranteed that the semantics are the same no matter how shared the tree structure is. `fold-const.c' still has some cases where this is not true, but rms hypothesizes that this will never be a problem.
템플릿은 TEMPLATE_DECL에 의해 표현된다. 특정 필드가 사용된다:
DECL_TEMPLATE_RESULT
DECL_TEMPLATE_PARMS
generic decl은 될 수 있는 대로 많이 다른 decl처럼 파스(parse)된다. generic decl은 parameterization이 주어진다. 템플릿 decl은 generic decl이 완료될때까지 만들어 지지 않는다. 템플릿 클래스에 대한 템플릿 decl은 게다가 각 멤버 함수와 정적 데이타 멤버에 대해 생성된다.
템플릿 클래스의 템플릿 멤버는 멤버의 매개변수에 대한 다른 TEMPLATE_DECL 주변의 클래스 매개변수에 대해 TEMPLATE_DECL에 의해 표현된다.
템플릿의 instantiation 이나 specialization 인 모든 선언은 DECL_TEMPLATE_INFO를 통해 그들의 템플릿과 매개변수로 언급된다.
어떻게 적절한 param decl을 가진 parsing member funcion을 취급해야하는가? 그것들을 다시 설정하거나 같은 것들을 사용하도록 시도해라? 현재 우리는 전자를 행한다. do_pending_inline안에 decl로부터 온 매개변수를 제거함으로써, store_pending_inline에 어떠한 여분의 기계없이 아마 이것을 할 수 있다. PRE_PARSED_TEMPLATE_DECL?
만약 base가 parm이라면, 그에 대한 어떠한 것도 검사할 수 없다. 만약 base가 parm이 아니라면, name binding에 대해 그것을 검사할 필요가 있다. 만약 어떠한 base도 parameterized하지 않다면(only if none,including indirect,are params) finish_base_struct를 행하라. 아니, 설치까지 이들중 어떤 것을 해볼려고 시도해서 괴롭히지 말라--우리는 단지 미리 name binding을 행하는 것이 필요하다.
Always set up method vec and fields, inc. synthesized mthods. 정말? 우리는 base와 field를 알때까지, copy folk의 형을 알 수 없거나 또는 우리가 소멸자를 필요로 한지를, 또는 디폴트 ctor를 가질 수 있는지를 알 수 없다. 그렇지 않으면 후에 자신이 직접 고칠 수 있다. 잘만되면..
함수 compute_access는 다음 세가지 값중 하나를 반환한다:
access_public
access_protected
access_private
DECL_ACCESS는 접속 선언을 위해 사용된다: alter_access는 형의 목록과 주어진 decl에 대한 접속을 생성한다.
전에, DECL_{PUBLIC, PROTECTED,PRIVATE} 은 compute_access의 반환 코드에 대응했고 compute_access를 위한 캐쉬(cache)로써 사용되었다. 이제 그것들은 전혀 사용되지 않는다.
TREE_PROTECTED, TREE_PRIVATE는 containing class에 의해 허용된 접속 수준(level)을 기록하는데 사용된다. 조심: TREE_PUBLIC은 접속 제어와 완전히 관계없는 어떤것을 의미한다!
C++ front-end는 형에 대한 적당한 문자열을 프린트하는 함수와 오류가 발견된 함수에 여분의 로직을 집어넣지 않는 함수를 허가하는 콜백(call-back) 메커니즘을 사용한다.
인터페이스는 cp_error 함수를 통해서 된다 (또는 cp_warning, 등). 문법은 몇가지 변환이 지원된다는 점을 제외하고는 error와 정확히 같다:
이들 사이에 몇가지 중복되는것이 있다: 예로써 노드 옵션중 어떤 것이든 식별자를 프린트하기위해 사용될 수 있다(비록 %D만은 함수명을 번역하려고 시도할지라도).
더 많은 verbose message에 대해(단순한 foo에 대립하는 것으로서 클래스 foo, 함수에 대한 반환 형을 포함하는), %#c를 사용하라.
오류 메시지상에 라인 수를 가지는 것은 DECL의 라인을 가르킨다. cp_error_at와 그것의 동류(同類;ilk)를 사용하라;
원하는 인자를 지시하기위해 %+D를 사용하라. 또는 그것은 우선 디폴트일 것이다.
파서(Parser)에 관한 몇가지 설명:
after_type_declarator / notype_declarator hack는 TYPENAME의 재선언을 허용하기위해 필요하다. 예를 들면,
typedef int foo;
class A {
char *foo;
};
위에서 첫번째 foo는 notype_declarator로써 파스된다. 그리고 두번째것은 after_type_declarator로써 파스된다.
모호성(Ambiguity):
일반적으로 파서에 4개의 reduce/reduce 모호성이 있다. 그것들은 다음과 같다:
1) tokens aggr identifier를 위한 template_parm과 named_class_head_sans_basetype 사이.
이러한 상황은 다음과 같은 코드에서 발생한다.
template <class T> class A { };
class T가 T라는 이름을 가진 템플릿형 매개변수의 선언로써 파스되야될지, 또는 class T 형의 이름이 없는 상수 매개변수로써 파스되야될지가 애매모호하다.
14.6절, '94년 1월 working paper의 3항(paragraph)은 최초의 해석이 옳다고 설명한다. 이것은 모호성이 2 reduce/reduce 충돌을 결과한다.
2) 둘다 허용될 수 있는 곳에 있는 `int()' 같은 코드에 대한 primary 와 type_id 사이. 이를 테면 sizeof에 대한 인자.
pre-San Diego working paper의 8.1절은 이러한 애미모호한 구성이 typename로써 해석될 것이라는 것을 명기한다.
이러한 모호성은 `absdcl'과 `functional_cast'사이의 6 reduce/reduce 충돌을 결과한다.
3) 다양한 token string을 위한 functional_cast와 complex_direct_notype_declarator 사이. 이러한 상황은 다음과 같은 코드에 발생한다.
int (*a);
이 코드는 애매모호하다: 그것은 `int'에 대한 포인토로써 변수 `a'의 선언이 될 수 있거나 `int' 에 대한 `*a'의 functional case가 될 수 있다. 6.8절은 이전의 해석이 옳다는 것을 명기한다. 이 모호성은 7 reduce/reduce 충돌을 결과한다. 이러한 모호성의 다른 양상은 'int (x[2]);' 같은 코드이다. 그리고 그것은 '['에서 해석되고 `direct_notype_declarator'과 `primary'/`overqualified_id' 사이의 6 reduce/reduce 충돌에 대한 원인이 된다. 결국, 'int (a);'같은 코드에 대한 `expr_or_declarator'과 `primary'사이의 4 r/r 충돌이 있다. 그리고 그것은 해석이 될지도 모르나 또한 그것의 가치보다 더 많은 문제가 될지도 모른다. 전부해서 이러한 상황은 17 충돌에 대한 원인이 된다. Ack!
위 두번째 경우는 객체 선언으로 LinppFile ppfile (String (argv[1]), &outs, argc, argv);' (from Rogue Wave Math.h++)를 파스하는 실패를 초래한다. 그리고 이후에까지 해석되지 않도록 고쳐져야 한다.
4) 간접적으로 after_type_declarator과 parm 사이. 이것은 다음과 같은 코드에서(한 예로써) 발생한다.
typedef int foo, bar;
class A {
foo (bar);
};
클래스 정의내에 bar는 무엇인가? 우리는 지금 Cfront를 행하는 것처럼 그것을 parm로써 해석한다.
그러나 IBM xIC는 after_type_declarator로써 그것을 해석한다.
"형명(type name)이 될 수 decl-specifiers의 가장 긴 열은 선언의 decl-specifier-seq 로써 취득된다."라고 말한 7.1p2로 미루어 보아 나는 xIC가 옳다고 믿는다.
그러나 이 규칙은 생성자의 경우에 위반됨이 틀림없다는 것이 분명한 것 같다. 이 모호성은 8 충돌에 대한 원인이 된다.
다른 것과 달리, 이 모호성은 Working Paper에 의해 인식되지 않는다.
Note, exception handling in g++ is still under development.
This section describes the mapping of C++ exceptions in the C++ front-end, into the back-end exception handling framework.
The basic mechanism of exception handling in the back-end is unwind-protect a la elisp. This is a general, robust, and language independent representation for exceptions.
The C++ front-end exceptions are mapping into the unwind-protect semantics by the C++ front-end. The mapping is describe below.
When -frtti is used, rtti is used to do exception object type checking, when it isn't used, the encoded name for the type of the object being thrown is used instead. All code that originates exceptions, even code that throws exceptions as a side effect, like dynamic casting, and all code that catches exceptions must be compiled with either -frtti, or -fno-rtti. It is not possible to mix rtti base exception handling objects with code that doesn't use rtti. The exceptions to this, are code that doesn't catch or throw exceptions, catch (...), and code that just rethrows an exception.
Currently we use the normal mangling used in building functions names (int's are "i", const char * is PCc) to build the non-rtti base type descriptors for exception handling. These descriptors are just plain NULL terminated strings, and internally they are passed around as char *.
In C++, all cleanups should be protected by exception regions. The region starts just after the reason why the cleanup is created has ended. For example, with an automatic variable, that has a constructor, it would be right after the constructor is run. The region ends just before the finalization is expanded. Since the backend may expand the cleanup multiple times along different paths, once for normal end of the region, once for non-local gotos, once for returns, etc, the backend must take special care to protect the finalization expansion, if the expansion is for any other reason than normal region end, and it is `inline' (it is inside the exception region). The backend can either choose to move them out of line, or it can created an exception region over the finalization to protect it, and in the handler associated with it, it would not run the finalization as it otherwise would have, but rather just rethrow to the outer handler, careful to skip the normal handler for the original region.
In Ada, they will use the more runtime intensive approach of having fewer regions, but at the cost of additional work at run time, to keep a list of things that need cleanups. When a variable has finished construction, they add the cleanup to the list, when the come to the end of the lifetime of the variable, the run the list down. If the take a hit before the section finishes normally, they examine the list for actions to perform. I hope they add this logic into the back-end, as it would be nice to get that alternative approach in C++.
On an rs6000, xlC stores exception objects on that stack, under the try block. When is unwinds down into a handler, the frame pointer is adjusted back to the normal value for the frame in which the handler resides, and the stack pointer is left unchanged from the time at which the object was thrown. This is so that there is always someplace for the exception object, and nothing can overwrite it, once we start throwing. The only bad part, is that the stack remains large.
The below points out some things that work in g++'s exception handling.
All completely constructed temps and local variables are cleaned up in all unwinded scopes. Completely constructed parts of partially constructed objects are cleaned up. This includes partially built arrays. Exception specifications are now handled. Thrown objects are now cleaned up all the time. We can now tell if we have an active exception being thrown or not (__eh_type != 0). We use this to call terminate if someone does a throw; without there being an active exception object. uncaught_exception () works. Exception handling should work right if you optimize. Exception handling should work with -fpic or -fPIC.
The below points out some flaws in g++'s exception handling, as it now stands.
Only exact type matching or reference matching of throw types works when -fno-rtti is used. Only works on a SPARC (like Suns) (both -mflat and -mno-flat models work), SPARClite, Hitachi SH, i386, arm, rs6000, PowerPC, Alpha, mips, VAX, m68k and z8k machines. SPARC v9 may not work. HPPA is mostly done, but throwing between a shared library and user code doesn't yet work. Some targets have support for data-driven unwinding. Partial support is in for all other machines, but a stack unwinder called __unwind_function has to be written, and added to libgcc2 for them. The new EH code doesn't rely upon the __unwind_function for C++ code, instead it creates per function unwinders right inside the function, unfortunately, on many platforms the definition of RETURN_ADDR_RTX in the tm.h file for the machine port is wrong. See below for details on __unwind_function. RTL_EXPRs for EH cond variables for && and || exprs should probably be wrapped in UNSAVE_EXPRs, and RTL_EXPRs tweaked so that they can be unsaved.
We only do pointer conversions on exception matching a la 15.3 p2 case 3: `A handler with type T, const T, T&, or const T& is a match for a throw-expression with an object of type E if [3]T is a pointer type and E is a pointer type that can be converted to T by a standard pointer conversion (_conv.ptr_) not involving conversions to pointers to private or protected base classes.' when -frtti is given.
We don't call delete on new expressions that die because the ctor threw an exception. See except/18 for a test case.
15.2 para 13: The exception being handled should be rethrown if control reaches the end of a handler of the function-try-block of a constructor or destructor, right now, it is not.
15.2 para 12: If a return statement appears in a handler of function-try-block of a constructor, the program is ill-formed, but this isn't diagnosed.
15.2 para 11: If the handlers of a function-try-block contain a jump into the body of a constructor or destructor, the program is ill-formed, but this isn't diagnosed.
15.2 para 9: Check that the fully constructed base classes and members of an object are destroyed before entering the handler of a function-try-block of a constructor or destructor for that object.
build_exception_variant should sort the incoming list, so that it implements set compares, not exact list equality. Type smashing should smash exception specifications using set union.
Thrown objects are usually allocated on the heap, in the usual way. If one runs out of heap space, throwing an object will probably never work. This could be relaxed some by passing an __in_chrg parameter to track who has control over the exception object. Thrown objects are not allocated on the heap when they are pointer to object types. We should extend it so that all small (<4*sizeof(void*)) objects are stored directly, instead of allocated on the heap.
When the backend returns a value, it can create new exception regions that need protecting. The new region should rethrow the object in context of the last associated cleanup that ran to completion.
The structure of the code that is generated for C++ exception handling code is shown below:
Ln: throw value;
copy value onto heap
jump throw (Ln, id, address of copy of value on heap)
try {
+Lstart: the start of the main EH region
|... ...
+Lend: the end of the main EH region
} catch (T o) {
...1
}
Lresume:
nop used to make sure there is something before
the next region ends, if there is one
... ...
jump Ldone
[
Lmainhandler: handler for the region Lstart-Lend
cleanup
] zero or more, depending upon automatic vars with dtors
+Lpartial:
| jump Lover
+Lhere:
rethrow (Lhere, same id, same obj);
Lterm: handler for the region Lpartial-Lhere
call terminate
Lover:
[
[
call throw_type_match
if (eq) {
] these lines disappear when there is no catch condition
+Lsregion2:
| ...1
| jump Lresume
|Lhandler: handler for the region Lsregion2-Leregion2
| rethrow (Lresume, same id, same obj);
+Leregion2
}
] there are zero or more of these sections, depending upon how many
catch clauses there are
----------------------------- expand_end_all_catch --------------------------
here we have fallen off the end of all catch
clauses, so we rethrow to outer
rethrow (Lresume, same id, same obj);
----------------------------- expand_end_all_catch --------------------------
[
L1: maybe throw routine
] depending upon if we have expanded it or not
Ldone:
ret
start_all_catch emits labels: Lresume,
The __unwind_function takes a pointer to the throw handler, and is expected to pop the stack frame that was built to call it, as well as the frame underneath and then jump to the throw handler. It must restore all registers to their proper values as well as all other machine state as determined by the context in which we are unwinding into. The way I normally start is to compile:
void *g; foo(void* a) { g = a; }
with -S, and change the thing that alters the PC (return, or ret usually) to not alter the PC, making sure to leave all other semantics (like adjusting the stack pointer, or frame pointers) in. After that, replicate the prologue once more at the end, again, changing the PC altering instructions, and finally, at the very end, jump to `g'.
It takes about a week to write this routine, if someone wants to volunteer to write this routine for any architecture, exception support for that architecture will be added to g++. Please send in those code donations. One other thing that needs to be done, is to double check that __builtin_return_address (0) works.
g++에서 예외처리는 아직 개발중임을 주의하라.
본 절은 back-end 예외 처리 구조안으로 C++ front-end내 C++ 예외의 매핑(mapping)을 기술한다.
back-end내 예외 처리의 기본 메커니즘은 unwind-protect a la elisp이다. 이것은 예외에 대한 일반적이고 튼튼하고 언어 독립적인 표현이다.
C++ front-end 예외는 C++ front-end에 의해 unwind-protect 의미론(semantics)안으로 매핑된다. 매핑은 아래에 기술된다.
-frtti 가 사용될 때, rtti는 예외 객체 형 검사(exception object type checking)를 행하는데 사용된다. 그것이 사용되지 않을때, 스로우(throw)된 객체의 형에 대한 코드화된 이름이 대신 사용된다. 예외를 일으킨 모든 코드, 동적 캐스팅(dynamic casting)처럼 심지어 부가적인 효과로 예외를 스로우(throw) 한 코드, 그리고 예외를 캐치(catch)한 모든 코드는 -frtti나 -fno-rtti를 가지고 컴파일되어야 한다. rtti base 예외 처리 객체를 rtti를 사용하지 않는 코드와 함께 섞어서 사용하는 것은 불가능하다. 이것에 대한 예외는 예외를 캐치하거나 스로우하지 않는 코드, catch (...), 예외를 다시 스로우만하는 코드이다.
요즘은 예외처리에 대한 non-rtti base type descriptor를 만들기위한 함수명을 만드는데 사용된 normal mangling을 사용한다. 이 descriptor는 단지 간단한 NULL terminated string 이고, 내부적으로 그것들은 char *로써 차례로 돌려진다.
C++에서 모든 cleanup은 예외 영역에 의해 보호되야 한다. 영역은 생성된 cleanup이 종료된 후에 바로 시작한다. 예로써 생성자를 가진 자동 변수를 가지고, 그것은 생성자가 동작한 후 정상이 될 것이다. 영역은 finalization이 확장되기 바로전에 끝난다. backend가 다른 경로(영역의 normal end에 대해 한번, non-local goto에 대해 한번, 반환에 대해 한번, 기타)를 따라 cleanup multiple times를 확장시킬지도 모르기 때문에, backend는 finalization 확장을 막는데 특별한 주의를 가져야 한다. 만약 확장이 normal region end보다 크다는 이유가 아닌 다른 이유라면, 그것은 'inline'이다(그것은 예외 영역안쪽이다). backend는 라인의 밖으로 그것들을 이동시킬 수 있거나, 그것을 보호하는 finalization에 관한 예외 영역을 생성할 수 있고, 그것과 연관된 핸들러(handler) 내에 예외 영역을 생성할 수 있다. 그것은 그것이 가지고 있는 것과 달리 finalization을 동작시키는 것이 아니라 오히려 원래 영역에 대한 normal 핸들러를 건너뛰는 것에 주의하여 외곽의 핸들러에게 재 스로우한다.
Ada에서 그것들은 더 적은 영역을 가진 좀더 runtime 집약적인 접근을 이용할 것이다. 그러나 실행 시간에 부가적인 작업의 비용면에서 cleanup을 필요로하는 것들의 목록을 유지할 것이다. 변수가 구성을 끝냈을 때, 그것들은 목록은 cleanup을 추가한다. 변수의 수명이 다했을때, 목록을 훓어본다. 만약 절(section)이 정상적으로 끝나기 전에 찾는다면, 그것들은 수행한 행위를 위해 목록을 조사한다. 나는 그들이 back-end내에 이 로직을 추가하기를 희망한다. C++에서 다른 접근법을 얻기에 좋을 것이다.
rs6000에서, xIC는 try 블록이하 그 스택상에 예외 객체를 저장한다. 핸들러 안에서 풀려 내려갈때, 프레임 포인터는 핸들러가 존재하는 프레임에 대한 정상값으로 조정된다. 그리고 스택포인터는 객체가 스로우된 시간부터 변경되지 않은채로 놓아둔다. 이것은 예외 객체를 위한 어떤 장소가 항상 존재한다는 것이다. 그리고 만약 스로우를 시작한다면 어떤 것도 그것을 덮어쓸 수 없다. 유일한 결점은 스택이 큰채로 있다는 것이다.
아래는 g++의 예외 처리에서 동작하는 몇가지 것들을 지적한다.
모든 완전히 구성된 temp와 지역 변수는 모든 unwinded 범위에서 제거된다. 부분적으로 구성된 객체의 완전히 구성된 부분은 제거된다. 이것은 부분적으로 만들어진 배열을 포함한다. 예외 규정(exception specification)은 이제 처리된다. 스로우된 객체는 이제 항상 제거된다. 우리는 이제 스로운된 활성 예외(active exception)를 가지고 있는 아닌지(__eh_type != 0)를 말할 수 있다. 만약 누군가가 스로우를 행했다면, terminate를 호출하는데 이것을 사용할 수 있다; 활성화된 예외 객체없이 uncauht_exception ()는 동작한다. 만약 최적화한다면 예외 처리는 제대로 동작해야 한다. 예외 처리는 -fpic 또는 -fPIC를 가지고 동작해야 한다.
아래는 g++의 예외 처리에서 몇가지 결점을 지적한다. 그것은 현재 존재한다.
스로우 형의 정확한 형 매칭(type matching)이나 참조 매칭(reference matching)만이 -fno-rtti가 사용될 때 동작한다. SPARC(Suns와 같은)(-mflat와 -mno-flat 모델모두 동작한다), SPARClite, Hitachi SH, i386, arm, rs6000, PowerPC, Alpha, mips, VAX, m68k, z8k 기계에서만 동작한다. SPARC v9는 동작 안할지도 모른다. HPPA는 거의 된다. 그러나 공유 라이브러리와 사용자 코드사이에서 스로우하는것은 아직 동작하지 않는다. 몇몇 타겟은 데이타 구동 unwinding에 대한 지원을 가지고 있다. 부분적인 지원은 모든 다른 기계에 대해 있다. 그러나 __unwind_function이라 불리는 스택 unwinder는 써져야 한다. 그리고 그것들을 위해 libgcc2에 추가되어져야 한다. 새로운 EH 코드는 C++ 코드를 위한 __unwind_function에 의지하지 않는다. 그 대신에 함수 바로안쪽에 각 function unwinder를 생성한다. 불행히도 많은 플랫폼(platform)에 대해 기계 포트(machine port)를 위한 tm.h 파일내 RETURN_ADDR_RTX의 정의는 틀리다. __unwind_function에 관한 자세한 사항에 대해서는 아래를 보라. &&과 || expr에 대한 EH cond 변수를 위한 RTL_EXPR는 어쩌면 UNSAVE_EXPR안에 둘러싸여야 한다. 그리고 RTL_EXPR은 그것들이 구제될 수 없도록(unsaved) 조정되어야 한다.
우리는 오직 예외 매칭 a la 15.3 p2 case3에 관한 포인터 변환만 행한다: 'type T, const T, T&, const T&를 가진 핸들러는 만약 [3]T가 포인터 형이고 private나 protected base 클래스에 대한 포인터의 변환을 포함하지 않는 표준 포인터 변환(_conv.prt_)에 의해 T로 변환될 수 있는 포인터형이라면 type E의 객체를 가진 스로우 표현에 대한 한 짝이다.' E가 -frtti가 주어질때
ctor가 예외를 스로우했기때문에 죽는 새로운 표현에 대해 delete를 호출하지 않는다. 시험 사례에 대해 except/18을 보라.
15.2 para 13: 만약 제어가 생성자 또는 소멸자의 function-try-block의 핸들러의 끝에 도달한다면, 처리된 예외는 재 스로우되야 한다. 바로 지금. 그것은 아니다.
15.2 para 12: 만약 반환 문장이 생성자의 function-try-block의 핸들러에 나타난다면, 그 프로그램은 나쁜 형태다. 그러나 이것은 진단되지 않는다.
15.2 para 11: 만약 function-try-block의 핸들러가 생성자 또는 소멸자의 몸체(body)안으로의 점프를 포함한다면, 그 프로그램은 나쁜 형태다. 그러나 이것은 진단되지 않는다.
15.2 para 9: 완전히 구성된 base 클래스와 객체의 멤버는 그 객체에 대한 생성자와 소멸자의 function-try-block의 핸들러를 들어가기전에 파괴된다는 것을 검사하라.
세트(set) 비교를 수행하도록 build_exception_variant는 incoming list를 정렬해야 한다. not exact list equality. type smashing은 set union을 이용한 예외 규정을 깨뜨려야 한다.
스로우된 객체는 일반적인 방법으로 보통 힙(heap)에 할당된다. 만약 하나가 힙 공간에서 나온다면, 객체를 스로우하는것은 아마 결코 동작하지 않을 것이다. 이것은 예외 객체에 관한 제어를 가진 track에 __in_chrg 매개변수를 전달함으로써 다소 느슨해질 수 있다. 스로우된 객체는 그것들이 객체형에 대한 포인터일때 힙에 할당되지 않는다. 우리는 모든 작은 (<4*sizeof(void*)) 객체가 힙에 할당되는 대신에 직접 저장되도록 그것을 확장해야 한다.
backend가 값을 반환할때, 그것은 보호가 필요한 새로운 예외 영역을 생성할 수 있다. 그 새로운 영역은 완성된 last associated cleanup의 문맥내 객체를 재 스로우해야 한다.
C++ 예외 처리 코드를 위해 생성된 코드의 구조를 아래 보인다:
Ln: throw value;
copy value onto heap
jump throw (Ln, id, address of copy of value on heap)
try {
+Lstart: the start of the main EH region
|... ...
+Lend: the end of the main EH region
} catch (T o) {
...1
}
Lresume:
nop used to make sure there is something before
the next region ends, if there is one
... ...
jump Ldone
[
Lmainhandler: handler for the region Lstart-Lend
cleanup
] zero or more, depending upon automatic vars with dtors
+Lpartial:
| jump Lover
+Lhere:
rethrow (Lhere, same id, same obj);
Lterm: handler for the region Lpartial-Lhere
call terminate
Lover:
[
[
call throw_type_match
if (eq) {
] these lines disappear when there is no catch condition
+Lsregion2:
| ...1
| jump Lresume
|Lhandler: handler for the region Lsregion2-Leregion2
| rethrow (Lresume, same id, same obj);
+Leregion2
}
] there are zero or more of these sections, depending upon how many
catch clauses there are
----------------------------- expand_end_all_catch --------------------------
here we have fallen off the end of all catch
clauses, so we rethrow to outer
rethrow (Lresume, same id, same obj);
----------------------------- expand_end_all_catch --------------------------
[
L1: maybe throw routine
] depending upon if we have expanded it or not
Ldone:
ret
start_all_catch emits labels: Lresume,
__unwind_function은 스로우 핸들러에 대한 포인터를 가진다. 그리고 프레임 바닥과 스로우 핸들러까지 점프뿐만 아니라 그것을 호출하기 위해 만들어진 스택 프레임을 팝(pop)하리라고 예상된다. 그 안으로 unwinding하고 있는 문맥(context)에 의해 결정된 것과 같이 모든 다른 기계 상태뿐만 아니라 그들의 적당한 값으로 모든 레지스터를 재저장해야 한다. 내가 일반적으로 시작하는 방법은 다음을 컴파일 하는 것이다:
void *g; foo(void* a) { g = a; }
-S를 가지고, PC를 변경하지 않도록 PC를 바꾸는 것들(일반적으로 return 또는 ret)을 변경하라. 꼭 모든 다른 의미론(스택 포인터나 프레임 포인터를 조정하는것 같이)을 남겨두어라. 그 이후 끝에서 한번더 prologue를 복제하라. 또 명령을 바꾸는 PC를 변경하라. 그리고 최종적으로 바로 그 끝에서 'g'까지 점프하라.
이 루틴을 작성하는 것은 약 일주일이 걸린다. 만약 누군가가 어떠한 아키텍쳐(architecture)에 대한 이 루틴을 작성하는 것을 자원하기를 원한다면, 그 아키텍쳐에 대한 예외 지원은 g++에 추가될 것이다. 그러한 코드 기증물을 보내주십시요. 수행될 필요가 있는 다른 것은 __builtin_return_address (0)가 동작하는 것을 이중 검사하는 것이다.
For the alpha, the __unwind_function will be something resembling:
void
__unwind_function(void *ptr)
{
/* First frame */
asm ("ldq $15, 8($30)"); /* get the saved frame ptr; 15 is fp, 30 is sp */
asm ("bis $15, $15, $30"); /* reload sp with the fp we found */
/* Second frame */
asm ("ldq $15, 8($30)"); /* fp */
asm ("bis $15, $15, $30"); /* reload sp with the fp we found */
/* Return */
asm ("ret $31, ($16), 1"); /* return to PTR, stored in a0 */
}
However, there are a few problems preventing it from working. First of
all, the gcc-internal function __builtin_return_address needs to
work given an argument of 0 for the alpha. As it stands as of August
30th, 1995, the code for BUILT_IN_RETURN_ADDRESS in `expr.c'
will definitely not work on the alpha. Instead, we need to define
the macros DYNAMIC_CHAIN_ADDRESS (maybe),
RETURN_ADDR_IN_PREVIOUS_FRAME, and definitely need a new
definition for RETURN_ADDR_RTX.
In addition (and more importantly), we need a way to reliably find the
frame pointer on the alpha. The use of the value 8 above to restore the
frame pointer (register 15) is incorrect. On many systems, the frame
pointer is consistently offset to a specific point on the stack. On the
alpha, however, the frame pointer is pushed last. First the return
address is stored, then any other registers are saved (e.g., s0),
and finally the frame pointer is put in place. So fp could have
an offset of 8, but if the calling function saved any registers at all,
they add to the offset.
The only places the frame size is noted are with the `.frame'
directive, for use by the debugger and the OSF exception handling model
(useless to us), and in the initial computation of the new value for
sp, the stack pointer. For example, the function may start with:
lda $30,-32($30) .frame $15,32,$26,0
The 32 above is exactly the value we need. With this, we can be sure
that the frame pointer is stored 8 bytes less--in this case, at 24(sp)).
The drawback is that there is no way that I (Brendan) have found to let
us discover the size of a previous frame inside the definition
of __unwind_function.
So to accomplish exception handling support on the alpha, we need two
things: first, a way to figure out where the frame pointer was stored,
and second, a functional __builtin_return_address implementation
for except.c to be able to use it.
Or just support DWARF 2 unwind info.
This subsection discusses various aspects of the design of the data-driven model being implemented for the exception handling backend.
The goal is to generate enough data during the compilation of user code,
such that we can dynamically unwind through functions at run time with a
single routine (__throw) that lives in libgcc.a, built by the
compiler, and dispatch into associated exception handlers.
This information is generated by the DWARF 2 debugging backend, and includes all of the information __throw needs to unwind an arbitrary frame. It specifies where all of the saved registers and the return address can be found at any point in the function.
Major disadvantages when enabling exceptions are:
The backend must be extended to fully support exceptions. Right now there are a few hooks into the alpha exception handling backend that resides in the C++ frontend from that backend that allows exception handling to work in g++. An exception region is a segment of generated code that has a handler associated with it. The exception regions are denoted in the generated code as address ranges denoted by a starting PC value and an ending PC value of the region. Some of the limitations with this scheme are:
The above is not meant to be exhaustive, but does include all things I have thought of so far. I am sure other limitations exist.
Below are some notes on the migration of the exception handling code backend from the C++ frontend to the backend.
NOTEs are to be used to denote the start of an exception region, and the end of the region. I presume that the interface used to generate these notes in the backend would be two functions, start_exception_region and end_exception_region (or something like that). The frontends are required to call them in pairs. When marking the end of a region, an argument can be passed to indicate the handler for the marked region. This can be passed in many ways, currently a tree is used. Another possibility would be insns for the handler, or a label that denotes a handler. I have a feeling insns might be the best way to pass it. Semantics are, if an exception is thrown inside the region, control is transferred unconditionally to the handler. If control passes through the handler, then the backend is to rethrow the exception, in the context of the end of the original region. The handler is protected by the conventional mechanisms; it is the frontend's responsibility to protect the handler, if special semantics are required.
This is a very low level view, and it would be nice is the backend supported a somewhat higher level view in addition to this view. This higher level could include source line number, name of the source file, name of the language that threw the exception and possibly the name of the exception. Kenner may want to rope you into doing more than just the basics required by C++. You will have to resolve this. He may want you to do support for non-local gotos, first scan for exception handler, if none is found, allow the debugger to be entered, without any cleanups being done. To do this, the backend would have to know the difference between a cleanup-rethrower, and a real handler, if would also have to have a way to know if a handler `matches' a thrown exception, and this is frontend specific.
The stack unwinder is one of the hardest parts to do. It is highly machine dependent. The form that kenner seems to like was a couple of macros, that would do the machine dependent grunt work. One preexisting function that might be of some use is __builtin_return_address (). One macro he seemed to want was __builtin_return_address, and the other would do the hard work of fixing up the registers, adjusting the stack pointer, frame pointer, arg pointer and so on.
operator new [] adds a magic cookie to the beginning of arrays
for which the number of elements will be needed by operator delete
[]. These are arrays of objects with destructors and arrays of objects
that define operator delete [] with the optional size_t argument.
This cookie can be examined from a program as follows:
typedef unsigned long size_t;
extern "C" int printf (const char *, ...);
size_t nelts (void *p)
{
struct cookie {
size_t nelts __attribute__ ((aligned (sizeof (double))));
};
cookie *cp = (cookie *)p;
--cp;
return cp->nelts;
}
struct A {
~A() { }
};
main()
{
A *ap = new A[3];
printf ("%ld\n", nelts (ap));
}
The linkage code in g++ is horribly twisted in order to meet two design goals:
1) Avoid unnecessary emission of inlines and vtables.
2) Support pedantic assemblers like the one in AIX.
To meet the first goal, we defer emission of inlines and vtables until the end of the translation unit, where we can decide whether or not they are needed, and how to emit them if they are.
alpha에 대해서 __unwind_function은 닮은 것이 될 것이다:
void
__unwind_function(void *ptr)
{
/* First frame */
asm ("ldq $15, 8($30)"); /* get the saved frame ptr; 15 is fp, 30 is sp */
asm ("bis $15, $15, $30"); /* reload sp with the fp we found */
/* Second frame */
asm ("ldq $15, 8($30)"); /* fp */
asm ("bis $15, $15, $30"); /* reload sp with the fp we found */
/* Return */
asm ("ret $31, ($16), 1"); /* return to PTR, stored in a0 */
}
그러나 몇가지 문제점들이 동작을 방해한다. 무엇보다도 gcc-내부 함수 __builtin_return_address는 alpha에 대해 주어진 0의 인자를 동작해야 한다.
현재로는 1995년 8월 30일의 것이다. `expr.c'에서 BUILT_IN_RETURN_ADDRESS에 대한 코드는 alpha상에서 확실히 동작하지 않는다.
그 대신에 매크로 DYNAMIC_CHAIN_ADDRESS(어쩌면), RETURN_ADDR_IN_PREVIOUS_FRAME를 정의해야한다. 그리고 RETURN_ADDR_RTX에 대한 새로운 정의가 꼭 필요하다.
게다가(그리고 좀더 중요하게) alpha에 관한 프레임 포인터를 확실히 찾을 수 있는 방법이 필요하다.
프레임 포인터(레지스터 15)를 재저장하기위해 위 8 값을 사용하는 것은 틀린것이다.
많은 시스템상에서 프레임 포인터는 스택상의 특정 지점에 대한 일관된 오프셋(offset)이다.
그러나 alpha상에서 프레임 포인터는 끝으로 밀려간다. 우선 반환 번지가 저장되고, 그다음 다른 레지스터가 저장된다(예를 들면, s0).
그리고 마지막으로 프레임 포인터는 적소에 놓인다. 그래서 fp는 8의 오프셋을 가질 수 있다.
그러나 만약 호출하는 함수가 어떤 레지스터를 조금이라도 저장했다면 그것들은 오프셋에 추가된다.
프레임 크기가 적힌 유일한 장소는 디버거와 (우리에게 필요없는) OSF 예외 처리 모델에 의해 사용을 위해,
스택포인터 sp를 위한 새로운 값의 초기 계산에서 `.frame' 지시문을 가지고 있다. 예로써, 함수는 다음을 가지고 시작할지도 모른다:
lda $30,-32($30) .frame $15,32,$26,0
위 32은 우리가 필요로 하는 바로 그 값이다. 이것을 가지고, 프레임 포인터는 8 바이트이하로 저장된다는 것을 확신할 수 있다.
-- 이 경우에 24(sp)에서. 단점은 내(Brendan)가 __unwind_function의 정의내에서 이전 프레임의 크기를 알도록 하는것을 찾을 방법이 없다는 것이다.
alpha에 대한 예외 처리 지원을 이루기위해 두가지가 필요하다:
첫번째는 프레임 포인터가 어디에 저장됬는지를 아는 방법, 두번째는 그것을 사용할 수 있는 except.c에 대한 functional __builtin_return_address 구현이다.
또는 단지 DWARF 2 unwind info를 지원한다.
여기서는 예외 처리 backend를 위해 구현된 데이타 구동 모드(data-driven mode)의 설계의 다양한 양상을 토의한다.
목적은 사용자 코드의 컴파일 동안에 충분한 데이타를 생성하는 것이다.
컴파일러에 의해 만들어진 libgcc.a에 있고 예외 핸들러안으로 디스패치하는 단일 루틴(__throw)을 가지고 실행 시간에 함수를 통해 동적으로 unwind할 수 있다.
이러한 정보는 DWARF 2 디버깅 backend에 의해 생성된다. 그리고 __throw가 임의의 프레임을 unwind해야한다는 정보에 관한 모든 것을 포함한다. 그것은 모든 저장된 레지스터와 복귀 번지가 함수내 어디에서 발견될 수 있는지를 명기한다.
예외가 활성화될때의 주요한 손실은 다음과 같다:
backend는 예외를 전적으로 지원하기위해 확장되어야 한다. 바로지금 g++에서 동작하는 예외 처리를 허용하는 backend로 부터 C++ frontend에 존재하는 alpha 예외 처리 backend에 몇가지 훅(hook)이 있다. 예외 영역은 그것과 연관된 핸들러를 가진 생성된 코드의 세그먼트이다. 예외 영역은 영역의 시작 PC값과 끝 PC값에 의해 표시된 번지 범위로써 생성된 코드에 표시된다. 이러한 구성이 가지는 몇가지 제한은 다음과 같다:
위는 철저하게 된다는 의미는 아니라 내가 지금까지 생각한 모든 것들을 포함한다는 것이다. 틀림없이 다른 제한이 존재한다.
아래는 C++ frontend로부터 backend까지 예외 처리 코드 backend의 이동에 관한 몇가지 기록이다.
NOTE는 예외 영역의 시작과 끝을 표시하는데 사용될 예정이다. 나는 backend에서 이들 note를 생성하는데 사용된 인터페이스가 두 함수(start_exception_region과 end_exception_region(또는 그와 같은 것))일 것이라고 생각한다. frontend는 그것들을 쌍으로 호출하도록 요구된다. 영역의 끝을 표시할 때, 인자는 표시된 영역을 위해 핸들러를 가리키기위해 통과될 수 있다. 이것은 여러가지 방법으로 통과될 수 있다. 현재는 트리가 사용된다. 다른 가능성은 핸들러에 대한 insns가 되거나 핸들러를 나타내는 라벨(label)이 된다. 나는 insns가 그것을 통과하는 가장 좋은 방법이라는 느낌을 가지고 있다. 의미론은 다음과 같다. 만약 예외가 그 영역내에 스로우된다면, 제어는 핸들러에게 무조건 전달된다. 만약 제어가 핸들러를 통해 지나간다면, backend는 원래 영역의 끝의 문맥에서 예외를 재 스로우할 것이다. 핸들러는 전통적인 메커니즘에 의해 보호된다; 만약 특별한 의미론이 요구된다면 핸들러를 보호하는 것은 frontend의 책임이다.
이것은 매우 낮은 수준의 관점이다. 그리고 그것은 이 관점에 더하여 다소 더 높은 수준의 관점이 지원되는 backend가 좋을 것이다. 이러한 더 높은 수준은 source line number, 원시파일 이름, 예외를 스로우한 언어의 이름과 어쩌면 예외의 이름을 포함한다. Kenner는 C++에 의해 단지 요구되는 기본사항보다 더 많이 하도록 당신을 올가맬지도 모른다. 당신을 이것을 해결해야 할것이다. 그가 당신이 non-local goto에 대한 지원을 하기를 원할지도 모른다. 예외 핸들러에 대한 최초 검색은 만약 아무것도 찾지 못한다면 완료된 어떠한 cleanup없이 디버거가 시작되도록 허용한다. 이같이 하기위해, backend는 cleanup-rethrower와 실제 핸들러사이의 차이를 알아야 한다. 만약 핸들러가 스로우된 예외에 `어울리는지'를 아는 방법을 가져야 한다면 이것은 frontend specific이다.
스택 unwinder는 해야할 가장 힘든 부분중 하나이다. 크게 기계의존적이다. kenner가 좋아하는 것처럼 보이는 형태는 기계의존적 grunt work를 하는 한 쌍의 매크로이다. 가끔 사용될지도 모르는 전에 존재하던 함수는 __builtin_return_address() 이다. 그가 원했던 한 매크로는 __builtin_return_address 이고 다른 하나는 레지스터를 고치고 스택 포인터, 프레임 포인터, arg 포인터를 조정하는 등의 어려운 일을 한다.
연산자 new[] 는 인자의 수가 연산자 delete[]에 의해 필요하게될 배열의 처음에 magic cookie를 추가한다.
이것들은 소멸자를 가진 객체의 배열과 optional size_t 인자를 가지고 연산자 delete []를 정의한 객체의 배열이다.
이 cookie는 아래와 같이 프로그램으로 부터 조사될 수 있다.
typedef unsigned long size_t;
extern "C" int printf (const char *, ...);
size_t nelts (void *p)
{
struct cookie {
size_t nelts __attribute__ ((aligned (sizeof (double))));
};
cookie *cp = (cookie *)p;
--cp;
return cp->nelts;
}
struct A {
~A() { }
};
main()
{
A *ap = new A[3];
printf ("%ld\n", nelts (ap));
}
g++에서 연결 코드는 두가지 설계 목표에 맞추기 위해 끔찍하게 꼬였다:
1) inline와 vtable의 불필요한 emission을 피하라.
2) AIX에서 처럼 pedantic assembler를 지원하라.
첫번째 목표에 맞추기 위해 번역 장치(translation unit)의 종료까지 inline과 vtable의 emission을 미룬다.
여기서 우리는 그것들이 필요한지 아닌지를 결정할 수 있다. 그리고 만약 있다면 그것들을 어떻게 emit할지를 결정할 수 있다.
Both C++ and Java provide overloaded functions and methods,
which are methods with the same types but different parameter lists.
Selecting the correct version is done at compile time.
Though the overloaded functions have the same name in the source code,
they need to be translated into different assembler-level names,
since typical assemblers and linkers cannot handle overloading.
This process of encoding the parameter types with the method name
into a unique name is called name mangling. The inverse
process is called demangling.
It is convenient that C++ and Java use compatible mangling schemes,
since the makes life easier for tools such as gdb, and it eases
integration between C++ and Java.
Note there is also a standard "Jave Native Interface" (JNI) which
implements a different calling convention, and uses a different
mangling scheme. The JNI is a rather abstract ABI so Java can call methods
written in C or C++;
we are concerned here about a lower-level interface primarily
intended for methods written in Java, but that can also be used for C++
(and less easily C).
Note that on systems that follow BSD tradition, a C identifier
C++ mangles a method by emitting the function name, followed by
For example
For a constructor, the method name is left out.
That is
GNU Java does the same.
The C++ types
The C++ and Java floating-point types
The C++
The C++
The Java integral types
C++ code that has included
A simple class, package, template, or namespace name is
encoded as the number of characters in the name, followed by
the actual characters. Thus the class
If any of the characters in the name are not alphanumeric
(i.e not one of the standard ASCII letters, digits, or '_'),
or the initial character is a digit, then the name is
mangled as a sequence of encoded Unicode letters.
A Unicode encoding starts with a `U' to indicate
that Unicode escapes are used, followed by the number of
bytes used by the Unicode encoding, followed by the bytes
representing the encoding. ASSCI letters and
non-initial digits are encoded without change. However, all
other characters (including underscore and initial digits) are
translated into a sequence starting with an underscore,
followed by the big-endian 4-hex-digit lower-case encoding of the character.
If a method name contains Unicode-escaped characters, the
entire mangled method name is followed by a `U'.
For example, the method
A C++ pointer type is mangled as `P' followed by the
mangling of the type pointed to.
A C++ reference type as mangled as `R' followed by the
mangling of the type referenced.
A Java object reference type is equivalent
to a C++ pointer parameter, so we mangle such an parameter type
as `P' followed by the mangling of the class name.
Squangling (enabled with the `-fsquangle' option), utilizes the
`B' code to indicate reuse of a previously seen type within an
indentifier. Types are recognized in a left to right manner and given
increasing values, which are appended to the code in the standard
manner. Ie, multiple digit numbers are delimited by `_'
characters. A type is considered to be any non primitive type,
regardless of whether its a parameter, template parameter, or entire
template. Certain codes are considered modifiers of a type, and are not
included as part of the type. These are the `C', `V',
`P', `A', `R', `U' and `u' codes, denoting
constant, volatile, pointer, array, reference, unsigned, and restrict.
These codes may precede a `B' type in order to make the required
modifications to the type.
For example:
Produces the mangled name `f__FGt6class21Zt6class11Z6class3iRCB1PB2'.
The int parameter is a basic type, and does not receive a B encoding...
Both C++ and Java allow a class to be lexically nested inside another
class. C++ also supports namespaces.
Java also supports packages.
These are all mangled the same way: First the letter `Q'
indicates that we are emitting a qualified name.
That is followed by the number of parts in the qualified name.
If that number is 9 or less, it is emitted with no delimiters.
Otherwise, an underscore is written before and after the count.
Then follows each part of the qualified name, as described above.
For example
Squangling utilizes the the letter `K' to indicate a
remembered portion of a qualified name. As qualified names are processed
for an identifier, the names are numbered and remembered in a
manner similar to the `B' type compression code.
Names are recognized left to right, and given increasing values, which are
appended to the code in the standard manner. ie, multiple digit numbers
are delimited by `_' characters.
For example
Function `f()' would be mangled as :
`f__FR6AndrewRQ2K07WasHereRQ2K110AndHereToo'
There are some occasions when either a `B' or `K' code could
be chosen, preference is always given to the `B' code. Ie, the example
in the section on `B' mangling could have used a `K' code
instead of `B2'.
A class template instantiation is encoded as the letter `t',
followed by the encoding of the template name, followed
the number of template parameters, followed by encoding of the template
parameters. If a template parameter is a type, it is written
as a `Z' followed by the encoding of the type. If it is a
template, it is encoded as `z' followed by the parameter
of the template template parameter and the template name.
A function template specialization (either an instantiation or an
explicit specialization) is encoded by an `H' followed by the
encoding of the template parameters, as described above, followed by an
`_', the encoding of the argument types to the template function
(not the specialization), another `_', and the return type. (Like
the argument types, the return type is the return type of the function
template, not the specialization.) Template parameters in the argument
and return types are encoded by an `X' for type parameters,
`zX' for template parameters,
or a `Y' for constant parameters, an index indicating their position
in the template parameter list declaration, and their template depth.
C++ array types are mangled by emitting `A', followed by
the length of the array, followed by an `_', followed by
the mangling of the element type. Of course, normally
array parameter types decay into a pointer types, so you
don't see this.
Java arrays are objects. A Java type
Both C++ and Java classes can have static fields.
These are allocated statically, and are shared among all instances.
The mangling starts with a prefix (`_' in most systems), which is
followed by the mangling
of the class name, followed by the "joiner" and finally the field name.
The joiner (see
For example
If the name of a static variable needs Unicode escapes,
the Unicode indicator `U' comes before the "joiner".
This
The following special characters are used in mangling:
The letters `G', `M', `O', and `p'
also seem to be used for obscure purposes ...
원문시작
Function name mangling for C++ and Java
var
would get "mangled" into the assembler name `_var'. On such
systems, all other mangled names are also prefixed by a `_'
which is not shown in the following examples.
Method name mangling
__,
followed by encodings of any method qualifiers (such as const),
followed by the mangling of the method's class,
followed by the mangling of the parameters, in order.
Foo::bar(int, long) const is mangled
as `bar__C3Fooil'.
Foo::Foo(int, long) const is mangled
as `__C3Fooil'.
Primitive types
int, long, short, char,
and long long are mangled as `i', `l',
`s', `c', and `x', respectively.
The corresponding unsigned types have `U' prefixed
to the mangling. The type signed char is mangled `Sc'.
float and double
are mangled as `f' and `d' respectively.
bool type and the Java boolean type are
mangled as `b'.
wchar_t and the Java char types are
mangled as `w'.
byte, short, int
and long are mangled as `c', `s', `i',
and `x', respectively.
javatypes.h will mangle
the typedefs jbyte, jshort, jint
and jlong as respectively `c', `s', `i',
and `x'. (This has not been implemented yet.)
Mangling of simple names
Foo
is encoded as `3Foo'.
X\u0319::M\u002B(int) is encoded as
`M_002b__U6X_0319iU'.
Pointer and reference types
Squangled type compression
template <class T> class class1 { };
template <class T> class class2 { };
class class3 { };
int f(class2<class1<class3> > a ,int b, const class1<class3>&c, class3 *d) { }
B0 -> class2<class1<class3>
B1 -> class1<class3>
B2 -> class3
Qualified names
Foo::\u0319::Bar is encoded as
`Q33FooU5_03193Bar'.
class Andrew
{
class WasHere
{
class AndHereToo
{
};
};
};
f(Andrew&r1, Andrew::WasHere& r2, Andrew::WasHere::AndHereToo& r3) { }
K0 -> Andrew
K1 -> Andrew::WasHere
K2 -> Andrew::WasHere::AndHereToo
Templates
Arrays
T[] is mangled
as if it were the C++ type JArray<T>.
For example java.lang.String[] is encoded as
`Pt6JArray1ZPQ34java4lang6String'.
Static fields
JOINER in cp-tree.h) is a special
separator character. For historical reasons (and idiosyncracies
of assembler syntax) it can `$' or `.' (or even
`_' on a few systems). If the joiner is `_' then the prefix
is `__static_' instead of just `_'.
Foo::Bar::var (or Foo.Bar.var in Java syntax)
would be encoded as `_Q23Foo3Bar$var' or `_Q23Foo3Bar.var'
(or rarely `__static_Q23Foo3Bar_var').
\u1234Foo::var\u3445 becomes _U8_1234FooU.var_3445.
Table of demangling code characters
bool type,
and the Java boolean type.
char type, and the Java byte type.
const type.
Also used to indicate a const member function
(in which cases it precedes the encoding of the method's class).
double types.
....
float types.
int types.
intn_t, where n is a
positive decimal number. The `I' is followed by either two
hexidecimal digits, which encode the value of n, or by an
arbitrary number of hexidecimal digits between underscores. For
example, `I40' encodes the type int64_t, and `I_200_'
encodes the type int512_t.
long type.
long double type.
short types.
char.
Also used as a modifier to indicate a static member function.
restrict type qualifier.
void types.
volatile type or method.
wchar_t type, and the Java char types.
long long type, and the Java long type.
Concept Index
p
원문끝
C++과 Java는 둘다 오버로드된 함수와 메서드를 제공한다. 그리고 이것은 같은 형을 가지지만 매개변수 목록이 다르다. 옳바른 버전을 선택하는 것은 컴파일 시간에 수행된다. 오버로드된 함수가 원시 코드안에 같은 이름을 가지고 있을지라도 다른 assembler-level 이름으로 번역되야한다. 왜냐하면 전형적인 어셈블러와 링커는 오버로딩(overloading)을 취급할 수 없기때문이다. 메서드 이름을 가진 매개변수 형을 유일한 이름으로 인코딩하는 과정을 name mangling라고 일컫는다. 반대 과정을 demangling이라고 일컫는다.
C++과 Java가 호환가능한 mangling 구성을 사용하는 것은 편리하다. 왜냐하면 gdb같은 툴을 더 쉽게 사용하도록 하고, C++과 Java 사이의 통합을 쉽게한다.
다른 호출 규정을 실행하고 다른 mangling 구성(scheme)을 사용하는 표준 "Java Native Interface" (JNI)가 또한 있다는 것을 주지하라. JNI는 상당히 추상적인 ABI이어서 Java는 C나 C++로 작성된 메서드를 호출할 수 있다: 여기서 우리는 Java로 작성된 메서드를 위해 최초로 지정된 lower-level interface에 관심이 있다. 그러나 그것은 또한 C++에 대해 사용될 수 있다(그리고 C에서는 덜 쉽게 사용된다).
BSD tradition을 따르는 시스템상에서 C 식별자 var는 어셈블러명 `_var'로 "mangle" 될 것이다. 그런 시스템에서 모든 다른 mangled name는 또한 다음 예에서 보여지지 않은 `_'가 앞에 붙는다.
C++은 함수명, 다음에 __, 다음에 어떤 (const같은) 메서드 qualifier, 다음에 메서드 클래스의 mangling, 다음에 매개변수의 mangling 순으로 emit함으로써 메서드를 mangle한다.
예를 들면, Foo::bar(int, long) const 는 `bar__C3Fooil'로 mangle된다.
생성자에 대해, 메서드명은 생략된다. 즉, Foo::Foo(int, long) const는 `__C3Fooil'로 mangle된다.
GNU Java는 똑같이 행한다.
C++ 형 int, long, short, char, long long는 `i', `l',`s', `c', `x'로 각각 mangle된다.
대응하는 unsigned 형은 mangling한것 앞에 `U'가 붙는다. signed char은 `Sc'로 mangle된다.
C++과 Java 부동소수점형인 float와 double은 각각 `f'와 `d'로 mangle된다.
C++ bool 형과 Java boolean 형은 `b'로 mangle된다.
C++ wchar_t과 Java char 형은 `w'로 mangle된다.
Java 정수형인 byte, short, int, long는 `c', `s', `i', `x'로 각각 mangle된다.
javatypes.h를 포함하고 있는 C++ 코드는 typedef인 jbyte, jshort, jint, jlong를 각각 `c', `s', `i', `x'로 mangle할 것이다.(이것은 아직 구현되지 않고 있다.)
간단한 class, package, template, namespace 명은 이름내 문자수, 다음에 실제 문자로 코드화 된다. 이렇듯 클래스 Foo는 `3Foo'로 코드화된다.
이름내 문자중 어떤 것이 alphanumeric(즉, 표준 ASCII문자, 숫자, 또는 '_'중의 하나가 아닌)이 아니거나 처음 문자가 숫자라면, 이름은 encoded Unicode 문자의 열로써 mangle된다. Unicode 인코딩은 Unicode escape가 사용된다는 것을 가르키기위해 `U'로 시작한다. 다음에 Unicode 인코딩에 사용된 바이트수, 다음에 인코딩을 표시하는 바이트. ASCII 문자와 맨앞에 위치하지 않는 숫자는 변경없이 인코딩된다. 그러나 (맨앞에 위치하는 숫자와 밑줄을 포함하는) 다른 모든 문자들은 밑줄을 가지고 시작하는 열로 번역된다. 다음에 문자의 big-endian 4-hex-digit lower case encoding.
만약 메서드명이 Unicode-escaped 문자를 가지고 있다면, 전체 mangle된 메서드명 다음에 `U'가 온다.
예를 들면, 메서드 X\u0319::M\u002B(int) 는 `M_002b__U6X_0319iU'로 인코딩된다.
C++ 포인터형은 `P' 다음에 지정된 형의 mangling으로 mangle된다.
C++ 참조형은 `R' 다음에 참조된 형의 mangling으로 mangle된다.
Java 객체 참조형은 C++ 포인터 매개변수에 해당한다. 그래서 `P' 다음에 클래스명의 mangling으로 그런 매개변수형을 mangle한다.
(`-fsquangle' 옵션으로 활성화된) squangling은 식별자안에 전에 보여진 형의 재사용(reuse)을 가르키는데에 `B' 코드를 이용한다. 형은 왼쪽에서 오른쪽으로의 방법과 표준방법에서 코드에 덧붙여진 주어진 증가값에서 인식된다. 즉, 여러자리(multiple digit) 숫자는`_' 문자로 구분된다. 형은 그것이 매개변수, 템플릿 매개변수 또는 entire template건 상관없이 비원형(non primitive type)이 되리라 생각된다. 어떤 코드는 형의 modifier로 고려되고, 형의 일부로써 포함되지 않는다. 이것들은 `C', `V', `P', `A', `R', `U', `u' 코드이다. 상수, volatile, 포인터, 배열, 참조, unsigned, restrict를 나타낸다. 이들 코드는 형에 대한 필요한 변경을 수행하기위해 `B' 형에 앞설지도 모른다.
예를 들면:
template <class T> class class1 { };
template <class T> class class2 { };
class class3 { };
int f(class2<class1<class3> > a ,int b, const class1<class3>&c, class3 *d) { }
B0 -> class2<class1<class3>
B1 -> class1<class3>
B2 -> class3
mangle된 이름 `f__FGt6class21Zt6class11Z6class3iRCB1PB2'를 만들어라. Int 매개변수는 기본 형이고 B 인코딩을 받지 않는다.
C++과 Java는 한 클래스가 다른 클래스내에 어의적으로 놓여지는 것을 허용한다. C++은 또한 namespace를 지원한다. Java는 또한 package를 지원한다.
이것들은 모두 같은 방법으로 mangle된다: 우선 문자 `Q'는 우리가 qualified name을 emit하고 있다는 것을 가르킨다. 그것은 그 다음에 qualified name내에 부분(part)의 수가 따라온다. 만약 그 수가 9이하라면 경계기호없이 emit된다. 만약 그렇지 않다면 밑줄이 계수값 전,후에 쓰여진다. 그런다음 위에서 언급한 것과 같이qualified name의 각 부분을 따른다.
예를 들면 Foo::\u0319::Bar는 `Q33FooU5_03193Bar'로 인코딩된다.
squangling는 qualified name의 기억된 부분을 가르키는데 문자 `K'를 이용한다. Qualified name이 식별자에 대해 처리될 때, 이름들은 계수되고 `B' 형 압축코드에서와 비슷한 방법으로 기억된다. 이름들은 왼쪽에서 오른쪽, 그리고 표준방법에서 코드에 덧붙여진 주어진 증가값에서 인식된다. 즉, 즉, 여러자리 숫자는 `_' 문자로 구분된다.
예를 들면
class Andrew
{
class WasHere
{
class AndHereToo
{
};
};
};
f(Andrew&r1, Andrew::WasHere& r2, Andrew::WasHere::AndHereToo& r3) { }
K0 -> Andrew
K1 -> Andrew::WasHere
K2 -> Andrew::WasHere::AndHereToo
함수 `f()'는 다음과 같이 mangle될 것이다 : `f__FR6AndrewRQ2K07WasHereRQ2K110AndHereToo'
`B'나 `K' 코드가 선택될때 몇가지 기회가 있다. 우선권은 항상 `B' 코드에게 주어진다. 즉, `B' mangling에 관한 절의 예에서 `B2'대신에 `K' 코드가 사용될 수 있었을 텐데.
클래스 템플릿 instantiation은 문자 `t', 다음에 템플릿명의 인코딩, 다음에 템플릿 매개변수의 수, 다음에 템플릿 매개변수의 인코딩으로써 인코딩된다. 만약 템플릿 매개변수가 형(type)이라면 `Z' 다음에 형의 인코딩으로 쓰여질 것이다. 만약 그것이 템플릿이라면 `z' 다음에 템플릿 템플릿 매개변수의 매개변수와 템플릿명으로 인코딩될 것이다.
함수 템플릿 specialization(instantiation거나 explicit specialization거나)는 `H' 다음에 템플릿 매개변수의 인코딩,위에 언급한 것과 같이, 다음에 `_', 템플릿 함수(specializatio이 아닌)에 대한 인자형(argument type)의 인코딩, `_', 귀환형(return type)으로 인코딩된다. (인자형과 같이 귀환형은 함수 템플릿의 귀환형이다. specialization의 것이 아니다.) 인자와 귀환형에서 템플릿 매개변수는 형 매개변수(type parameter)에 대한 `X', 템플릿 매개변수에 대한 `zX', 또는 상수 매개변수, 템플릿 매개변수 목록 선언에서 그것들의 위치를 나타내는 인덱스, 템플릿 depth에 대한 `Y'에 의해 인코딩된다.
C++ 배열형은 `A', 다음에 배열의 길이, 다음에 `_', 다음에 요소형(element type)의 mangling을 emit함으로써 mangle된다. 물론, 일반적으로 배열 매개변수형은 포인터형안에서 소멸하므로 이것을 볼 수 없다.
Java 배열은 객체이다. Java 형 T[]는 마치 C++ 형 JArray<T>처럼 mangle된다.
예를 들면 java.lang.String[]는 `Pt6JArray1ZPQ34java4lang6String'로 mangle된다.
C++과 Java 클래스는 정적 필드를 가질 수 있다. 이것들은 정적으로 할당된다. 그리고 모든 인스턴스들에게 공유된다.
mangling은 접두어(대부분 시스템에서 `_')를 가지고 시작한다. 그리고 그것 다음에 클래스명의 mangling, 다음에 "joiner"와 마지막으로 필드명이 온다.
joiner(cp-tree.h에서 JOINER를 보라)는 특별한 분리자 문자(separator character)이다.
역사적 이유(그리고 어셈블러 구문의 특성) 때문에 그것은 `$'이거나 `.'(심지어 몇몇 시스템에서는 `_')일 수 있다.
만약 joiner가 `_'이라면 그때의 접두어는 바로 `_' 대신에 `__static_'이다.
예를 들면 Foo::Bar::var (또는 Java 구문에서 Foo.Bar.var)는 `_Q23Foo3Bar$var'또는 `_Q23Foo3Bar.var'(또는 드물게 `__static_Q23Foo3Bar_var')로 인코딩된다.
만약 정적 변수의 이름이 Unicode escapes을 필요로 한다면, Unicode indicator `U'는 "joiner"앞에 온다.
이 \u1234Foo::var\u3445는 _U8_1234FooU.var_3445가 된다.
다음 특별한 문자들은 mangling에서 사용된다:
bool형과 Java boolean형을 인코딩한다.
char형과 Java byte형을 인코딩한다.
const을 가리키기위한 modifier.
또한 const 멤버 함수를 가리키는데 사용된다.(메서드의 클래스의 인코딩을 우선하는 경우에)
double형을 인코딩한다.
...를 가리킨다.
float형을 인코딩한다.
int형을 인코딩한다.
intn_t형태의 typedef명을 인코딩한다. 여기서 n은 양의 십진수이다.
`I'는 다음에 n의 값을 인코딩하는 두자리 16진수나 밑줄사이에 임의의 16진수가 온다.
예를 들면, `I40'는 int64_t형을 인코딩하고, `I_200_'는 int512_t형을 인코딩한다.
long형을 인코딩한다.
long double형을 인코딩한다.
short을 인코딩한다.
char에서만 사용된다.
또한 정적 멤버 함수를 가리키기 위한 modifier로써 사용된다.
restrict 형 qualifier.
void형을 인코딩한다.
volatile형 또는 메서드를 위한 modifier.
wchar_t형과 Java char형을 인코딩한다.
long long형과 Java long형을 인코딩한다.
문자 `G', `M', `O', `p'는 또한 불분명한 목적을 위해 사용되는 것 같다.
처음, 이전, 다음, 마지막 절로 가기, 목차.