EHABI: Remaining issues

Hi Keith, Anton, Logan,

Last time we spoke about ARM unwinding, we agreed to have both CFI and
directive variants in ARM, so that both EH and debuggers/profilers
could correctly unwind the stack. The problem, obviously, is that we
now have redundant information and I decided to have a go commoning
them up.

One of the issues, I think, is GNU compatibility (so GAS can generate
the tables correctly when not using the integrated assembler), and it
seems there GCC also emits both EHABI directives and Dwarf, so I don't
think we'll be able to move away from it. Since this is only relevant
in debug/profiling mode, and the only problem is code size, I think
this is something we can live with. Do you guys agree with it?

Another issue is the usage of EH tables in C code. I believe the
consensus is that it may not be the most optimal for never-exceptional
code, but it's the safest default option. The only thing remaining is
to choose a way to disable them via some flag. As weird as
-fno-exceptions sounds for C code, I think we'll have to go with it.
Any other ideas?

Finally, Keith, do you have some internal EHABI test you can run Clang
on? Does any one know of a large, self contained code, that makes
heavy use of exceptions?

cheers,
--renato

Renato

From: Renato Golin [mailto:renato.golin@linaro.org]

Last time we spoke about ARM unwinding, we agreed to have both CFI and
directive variants in ARM, so that both EH and debuggers/profilers
could correctly unwind the stack. The problem, obviously, is that we
now have redundant information and I decided to have a go commoning
them up.

One of the issues, I think, is GNU compatibility (so GAS can generate
the tables correctly when not using the integrated assembler), and it
seems there GCC also emits both EHABI directives and Dwarf, so I don't
think we'll be able to move away from it. Since this is only relevant
in debug/profiling mode, and the only problem is code size, I think
this is something we can live with. Do you guys agree with it?

I think for the moment this is a sensible stance as it ensure maximum compatibility with debuggers who might understand DWARF but not EHABI generated tables.

Another issue is the usage of EH tables in C code. I believe the
consensus is that it may not be the most optimal for never-exceptional
code, but it's the safest default option. The only thing remaining is
to choose a way to disable them via some flag. As weird as
-fno-exceptions sounds for C code, I think we'll have to go with it.
Any other ideas?

It does seem strange if you are only compiling C code you have to specify -fno-exceptions in order to not generated the overhead of the exception tables.

Personally, it would appear to be more correct to require the use of -fexceptions if you want the overhead of exception tables when compiling C.

However I can see that this may result in people not using -fexecptions when they should and programs failing at runtime because of it. Whilst not specifying -fno-exceptions just results in a slightly larger image.

Finally, Keith, do you have some internal EHABI test you can run Clang
on? Does any one know of a large, self contained code, that makes
heavy use of exceptions?

The EHABI specific tests that we have, test the ARM EHABI personality routines whilst clang generates exception handling that use the GCC personality routines.

Otherwise the tests we have are generic exception handling tests that are part of C++ language tests suites.

Keith

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

Renato

From: Renato Golin [mailto:renato.golin@linaro.org]

Last time we spoke about ARM unwinding, we agreed to have both CFI and
directive variants in ARM, so that both EH and debuggers/profilers
could correctly unwind the stack. The problem, obviously, is that we
now have redundant information and I decided to have a go commoning
them up.

One of the issues, I think, is GNU compatibility (so GAS can generate
the tables correctly when not using the integrated assembler), and it
seems there GCC also emits both EHABI directives and Dwarf, so I don't
think we'll be able to move away from it. Since this is only relevant
in debug/profiling mode, and the only problem is code size, I think
this is something we can live with. Do you guys agree with it?

I think for the moment this is a sensible stance as it ensure maximum
compatibility with debuggers who might understand DWARF but not EHABI
generated tables.

Another issue is the usage of EH tables in C code. I believe the
consensus is that it may not be the most optimal for never-exceptional
code, but it's the safest default option. The only thing remaining is
to choose a way to disable them via some flag. As weird as
-fno-exceptions sounds for C code, I think we'll have to go with it.
Any other ideas?

It does seem strange if you are only compiling C code you have to specify
-fno-exceptions in order to not generated the overhead of the exception
tables.

Personally, it would appear to be more correct to require the use of
-fexceptions if you want the overhead of exception tables when compiling C.

However I can see that this may result in people not using -fexecptions when
they should and programs failing at runtime because of it. Whilst not
specifying -fno-exceptions just results in a slightly larger image.

Finally, Keith, do you have some internal EHABI test you can run Clang
on? Does any one know of a large, self contained code, that makes
heavy use of exceptions?

The EHABI specific tests that we have, test the ARM EHABI personality
routines whilst clang generates exception handling that use the GCC
personality routines.

Otherwise the tests we have are generic exception handling tests that are
part of C++ language tests suites.

Keith

Yes, it becomes a nuisance, not a failure. If you use g++ on C code,
you get the EH tables, but not if you use gcc. Having two separate
entry points help, but I don't think that clang/clang++ is in such a
position to so the same (I never use clang++, maybe I should...).

cheers,
--renato

One of the issues, I think, is GNU compatibility (so GAS can generate
the tables correctly when not using the integrated assembler), and it
seems there GCC also emits both EHABI directives and Dwarf, so I don't
think we'll be able to move away from it. Since this is only relevant
in debug/profiling mode, and the only problem is code size, I think
this is something we can live with. Do you guys agree with it?

I think emitting both is a good thing, personally. It means that
generic tools (and possibly even debuggers, given certain runtime
support) can rely on the DWARF standard, not just the bits we've
decided should apply to ARM.

It's easy to imagine some information-gathering tool that doesn't want
to add ARM-specific code-paths just to get some statistics from a
binary.

Cheers.

Tim.

Absolutely! I was actually trying to reduce (or remove) the ARM
specific directives and make the EHABI understand the CFI directives,
but that would be a IAS-only feature and we'd have to test both all
the time (more space for bugs).

cheers,
--renato

Sorry, I should have said "-fno-unwind-tables" here, which does make sense.

cheers,
--renato

Hi Renato,

I would like to know what do you mean by “commoning them up”?

I object to the idea to remove (or reduce) the ARM directives in favor of CFI directives, though I believe it will be good to emit both ARM directives and CFI directives so that some debugger or profiling tools can be used without implementing ARM-specific logic.

The main reason for the objection is the compatibility between the integrated-as and the binutils gas. What if we have to use gas to compile the output of LLVM? Although we are working hard to improve the integrated-as, but there are a lot of existing code simply doesn’t work when integrated-as is used. Some of the issues are even considered as a feature and marked as won’t fix.

For the space issue, I personally don’t think this is a big issue. For the code without exception handling, only stack informations will be encoded. Besides, the encoding format is very compact. In the common cases, the code without exception handling needs only 8-12 bytes per function. If this is still an issue, then -fno-unwind-table might be a solution (i.e. at llvm assembly level, the function should be marked with nounwind and without uwtable.)

Sincerely,
Logan

I would like to know what do you mean by "commoning them up"?

Hi Logan,

That'd be reducing ARM directives in favour of CFI, but as I said (and
you too), GNU compatibility will probably be an issue for a very long
time.

For the space issue, I personally don't think this is a big issue. For the
code without exception handling, only stack informations will be encoded.
Besides, the encoding format is very compact. In the common cases, the code
without exception handling needs only 8-12 bytes per function. If this is
still an issue, then -fno-unwind-table might be a solution (i.e. at llvm
assembly level, the function should be marked with nounwind and without
uwtable.)

Yes, and that's what my merge request implements:

http://llvm-reviews.chandlerc.com/D3079

As soon as that's in, I believe EHABI is finally in good shape to be
called Beta.

Since the 3.4 release I'm trying to get the EHABI and IAS support in
good shape (removing the final restraints, testing a lot), for them to
be enabled by default in 3.5, and I think we got it, thanks to you,
Anton, Saleem and many others.

cheers,
--renato

Hi Renato,

Although replacing ARM-specific directives in favor of CFI directives is a desirable movement, I think the compatibility should be considered carefully before we stop to emit the ARM-specific directives.

Maybe a reasonable criteria is that there are at least two major releases of GNU binutils assembler which can emit EHABI tables by reading CFI directives?

Sincerely,

Logan

This is a good criteria.

cheers,
--renato