[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/994] section switch in function causes segfault

From: wilson at specifixinc dot com
Subject: [Bug gas/994] section switch in function causes segfault
Date: 8 Jun 2005 18:48:59 -0000

------- Additional Comments From wilson at specifixinc dot com  2005-06-08 
18:48 -------
Nick's patch avoids the assembler core dump, but results in corrupted unwind
info.  IMHO, this is worse, since it converted an obvious error into a silent 

I'm thinking the assembler should emit a warning (or perhaps an error) when this
problem is seen.  Also, the IA-64 compiler should emit a warning (or perhaps an
error) when the -freorder-blocks-and-partition option is used, which will say
that the option isn't supported for IA-64.

It is exactly because of these kinds of problems why I keep saying that section
switching should be a hard error.  It will be so hard to modify the assembler to
get this case right that it likely isn't worth the trouble.  I think it is
better is to fix the compiler to avoid constructs like this.  It will probably
take a lot of compiler work too though.  The .text.unlikely code needs to be
emitted after the function end.  Also, you either need to guarantee that you
will never put any code in .text.unlikely that can throw an exception, or else
you need to emit proper unwind info for it.  Emitting proper unwind info for it
may require info about the context in which it is being called, in case we need
something more than just a body region.  Better might be to avoid such cases,
which means we need to avoid putting any function returns in a .text.unlikely
section, and we need to avoid putting any shrink wrapped prologue/epilogue code
in there, etc.

This is likely to be a big mess, even if implemented by someone who understands
IA-64 code.

On second thought, if this is a big enough mess in the compiler, then it might
be worthwhile to try to make this work in the assembler.  Getting this right in
the assembler means that a lot of the assembler internal data in tc-ia64.c needs
to be put in a structure and maintained separately for every text region, so
that we can handle nested text regions, pushing/popping text regions, etc, and
then still be able to sort everything out at the end.  My worry here though
would be that there are so few people who both understand the inner details of
how IA-64 code works, and are willing to do binutils work, that we may not be
able to find a competent volunteer to do this work.

           What    |Removed                     |Added
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]