This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

*** please, please, someone of the authors of the new exception mechanism, read it ***


Sorry for the strange subject, I've sent already this message once and got no sign of reply
for three days.

The problem is that I can't get the exception mechanism working without making changes
to dwarf2out.c and I _don't_ want this since it looks like a kludge to me.

My original message follows...

-------------------------------------------
Hello!

I have a strange problem with the dwarf2 frame info, maybe somebody can
clarify me. Here is a section from the cc1plus output with frame information,
the sequence of lines has not been changed from the original source, except
that I've inserted here and there some comments.

// Sidenote: the port I`m talking about uses a.out format.

[...]
	.align 2
___EXCEPTION_TABLE__:
	.long LEHB22
	.long LEHE22
	.long L22

	.long LEHB24
	.long LEHE24
	.long L24

	.long LEHB38
	.long LEHE38
	.long L38

	.long LEHB30
	.long LEHE30
	.long L30

	.long LEHB33
	.long LEHE33
	.long L33

___EXCEPTION_END__:
	.long -1
	.long -1
	.long -1
//
// this table is placed in the .code section, right after function body.
// IMHO this should be placed in the .data section, to avoid if possible
// loading it when no exceptions will occur.
//

.data
.globl __GLOBAL_$F$main
__GLOBAL_$F$main:
	.stabs "___EH_LIST__",24,0,0,__GLOBAL_$F$main

//
// I use .stabs to build a chained list of __GLOBAL_$X$XXXXX labels
// (analogous to ctors and dtors), to avoid running collect2.
// Then __main() calls __register_frame_table(&__EH_LIST__) to register
// entire list of __GLOBAL$X$XXXX's.
//

___FRAME_BEGIN__:
	.long LECIE1-LSCIE1

LSCIE1:
	.long 0

		.byte	0x1
	.ascii "eh\0"

	.long ___EXCEPTION_TABLE__

		.byte	0x1
		.byte	0x7c
		.byte	0x8
		.byte	0xc
		.byte	0x5
		.byte	0x4
		.byte	0x88
		.byte	0x1

	.align 2
LECIE1:

//
// Now look how CIE structure is defined in frame.c:
//
// struct dwarf_cie {
//   uword length;
//   sword CIE_id;
//   ubyte version;
//   char augmentation[0];
// } __attribute__ ((packed, aligned (__alignof__ (void *))));
//
// The comment above the definition of dwarf_cie says:
//
// /* The first few fields of a CIE.  The CIE_id field is 0xffffffff for a CIE,
//    to distinguish it from a valid FDE.  FDEs are aligned to an addressing
//    unit boundary, but the fields within are unaligned.  */
//
// First, I don't see CIE_id to be equal to 0xffffffff.
// Second, I don't understand why __GLOBAL_$F$main points to CIE instead
// of FDE, since as far as I understand __register_frame_table expects
// a pointer to FDE rather than to a CIE.
//

	.long LEFDE1-LSFDE1

LSFDE1:
	.long LSFDE1-___FRAME_BEGIN__

	.long LFB1

	.long LFE1-LFB1

		.byte	0x4
	.long LCFI0-LFB1

		.byte	0xe
		.byte	0x8
		.byte	0x84
		.byte	0x2
		.byte	0x4
	.long LCFI1-LCFI0

		.byte	0xd
		.byte	0x4
		.byte	0x4
	.long LCFI3-LCFI1

		.byte	0x83
		.byte	0x5
		.byte	0x4
	.long LCFI4-LCFI3

		.byte	0x2e
		.byte	0x4
		.byte	0x4
	.long LCFI5-LCFI4
[... and so on...]

//
// The above seems to be a FDE. But it can be referred only through
// LECIE1. This looks strange to me since I need a pointer to the FDE
// to register the exception region, and cannot use a local label for this.
//
// After thinking a bit I thought that dwarf2out::output_call_frame_info
// should put the get_file_function_name ('F') label between CIE and FDE.
// *OR* __register_frame_table should be modified to accept a list of
// pointers to CDEs rather than to FDEs.
//
// Now the question is: where am I wrong?
//

Greetings,
    _\ndy@teamOS/2



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]