EHABI: Remaining issues

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

EHABI: Remaining issues

Renato Golin-2
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: EHABI: Remaining issues

Keith Walker
Renato

> -----Original Message-----
> From: Renato Golin [mailto:[hidden email]]
>
> 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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: EHABI: Remaining issues

Keith Walker-2
In reply to this post by Renato Golin-2
Renato

> -----Original Message-----
> From: Renato Golin [mailto:[hidden email]]
>
> 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



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: EHABI: Remaining issues

Renato Golin-2
In reply to this post by Keith Walker
On 13 March 2014 16:48, Keith Walker <[hidden email]> wrote:
> Whilst not specifying -fno-exceptions just results in a slightly larger image.

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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: EHABI: Remaining issues

Tim Northover-2
In reply to this post by Renato Golin-2
> 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.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: EHABI: Remaining issues

Renato Golin-2
On 13 March 2014 19:13, Tim Northover <[hidden email]> wrote:
> 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.

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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: EHABI: Remaining issues

Renato Golin-2
In reply to this post by Keith Walker
On 13 March 2014 16:48, Keith Walker <[hidden email]> wrote:
> 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.

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

cheers,
--renato
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: EHABI: Remaining issues

Logan Chien
In reply to this post by Renato Golin-2
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


On Thu, Mar 13, 2014 at 9:15 PM, Renato Golin <[hidden email]> wrote:
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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: EHABI: Remaining issues

Renato Golin-2
On 15 March 2014 17:06, Logan Chien <[hidden email]> wrote:
> 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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: EHABI: Remaining issues

Logan Chien
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


On Sun, Mar 16, 2014 at 2:47 AM, Renato Golin <[hidden email]> wrote:
On 15 March 2014 17:06, Logan Chien <[hidden email]> wrote:
> 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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: EHABI: Remaining issues

Renato Golin-2
On 18 March 2014 18:02, Logan Chien <[hidden email]> wrote:
> 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?

This is a good criteria.

cheers,
--renato
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev