Re: Using the GCC EH mechanism for Ada

[Olivier Hainque <hainque at act-europe dot fr>]

First of all, thank you very much for your reply :)

Richard Henderson writes:
 > On Mon, Jun 18, 2001 at 07:20:52PM +0200, Olivier Hainque wrote:
 > >  What kind of argument should we provide to expand_start_catch when a
 > >  single handler is in place for several exceptions ?
 > 
 > A TREE_LIST, though that is not directly supported by the code now.

 > More thought will be required for assign_filter_values -- due to
 > the way the information is represented in the object file tables
 > you will need one filter value per exception type, which means
 > that one catch region will have more than one filter value.

 OK. This confirms my understanding after having looked at the code.
 
 Do you think mapping filter values to (pointers to) arrays could also do the
 trick ?

 > Some minor modifications will be needed in reachable_next_level.

 OK. I haven't looked at this part in detail yet. Simply noted that it seemed
 possible to not define lang_eh_type_covers.
  
 > Of course, this external representation is sort of optimized for
 > C++. There is no need for a completely common implementation, as
 > the language personality routine is the only thing that looks at
 > these tables.  If we can come up with a clean way to abstract this
 > (calling back into the front end), that would be a good thing.

 Well, unless I missed really important things (which is quite possible), the
 absraction level did not appear that low to me. The only point that mislead
 the basic initial adaptation to Ada a bit was simply the fact that "types"
 are referenced everywhere for information that does not necessarily represent
 actual types.  It turns out that this is the case for C++ which was the
 primary target, but the scheme appeared directly usable for Ada simply by
 providing pointers to exception descriptors (or possibly to arrays of such
 pointers, which is not implemented yet).

 Perhaps a first step towards a higher level of abstraction would be to give
 more general names to some functions/arguments/tables and such ?

 Thanks again for your help,

 Olivier