Re: generating functions and eh region
On Wed, 01 Apr 2009 11:22:22 -0700, Ian Lance Taylor
wrote:
> "Vincent R." writes:
>
>>> gcc will do the right thing if you put statements in an exception
>>> region.
>>
>> Hum how gcc can do that kind of things, is it some kind of voodoo ?
>> __except is not implemented yet and is more than a language construct
>> because it's an
>> OS thing.
>> So maybe I need to say it once again, instructions inside __except needs
>> to
>> be
>> put inside a function by the compiler .
>
> Can you explain why that is? I don't know how SEH works; how does the
> OS get involved?
>
Yes I can but I will talk only about table-based SEH available on RISC(ARM,
SH, MIPS) and x64 architecture
Mechanism is different on x86.
Usually with C++ exceptions you cannot catch for instance NULL pointer
exception ie
if you write something like that :
DWORD* ptr = NULL;
try
{
*ptr = 0X42; // access violation
}
catch(...)
{
}
it will segfault.
With SEH you can catch that kind of errors and that's why it's so
interesting in embedded world
To be able to do it, it means OS is involved.
When OS is initialized it registers exception table and when an exception
is raised it will look
what is Program Counter of the current process.
Then he will look inside a specific PE section that list address and length
of each function
available in the binary and check if the function has SEH.
If it has SEH it will look inside another table that will tell him to jump
to the associated filter function.
So when you declare this :
int _tmain(int argc, _TCHAR* argv[])
{
DWORD* ptr = NULL; // NULL pointer
__try
{
puts("in try");
*ptr = 0x4242;// causes an access violation exception;
}
__except(puts("in filter"), EXCEPTION_EXECUTE_HANDLER){
puts("in except");
}
puts("world");
return 0;
}
you will get the generated code as if you had written like that
.text
--
int wmain(int argc, _TCHAR* argv[])
{
DWORD* ptr = NULL; // NULL pointer
BEGINTRY: {
puts("in try");
*ptr = 0x4242;// causes an access violation exception;
ENDTRY: }
goto AEB;
JMPTGT: puts("in except");
AEB:
puts("world");
return 0;
}
int filter_func(unsigned int code, struct _EXCEPTION_POINTERS *ep)
{
puts("in filter_func");
return EXCEPTION_EXECUTE_HANDLER;
}
.xdata (or .pdata on wince)
FuncStart PrologLen FuncLen ThirtyTwoBit ExceptionFlag Comment
00011008 0x4 0x151 1 wmain
0001105c 0x1 0x9 1 0
So from this table we know that wmain starts at address 00011008 and finish
at address 00011008 + 0x15 = 0001101D
So when access violation is raised OS kernel looks Program Counter, in the
above case
it happens at 0001102C and he knows that problem is in wmain and that this
function has an associated SEH.
Then kernel looks inside another table that will tell him to jump to
filter_func().
The filter_func return a value to indicate if it want to handle this
exception and if yes
it will jump to Jump target address (JMPTGT label).
So code inside __except braces will be executed.
Hope you understand better.
Re: stdint.h type information needed
Dave Korn wrote:
> First attempt (attached) didn't go so well. When building libgcc2, I get
> an ICE in the preprocessor, here:
> As far as I can tell, CHAR16_TYPE is:
>
> (gdb) x/s 0x1fdb0f6 0x1fdb0f6 <__FUNCTION__.59453+167>: "unsigned
> short" (gdb)
>
> Is this perhaps related to the way all the short, long and longlong types
> in cygwin-stdint.h omit "int"?
Answering my own question: no, it's not.
char16_type_node exists, and looks like a valid type declaration to me, but
for some reason identifier_global_value() on it returns NULL.
$1 = (union tree_node *) 0x7ff31ab0
$2 = {base = {code = IDENTIFIER_NODE, side_effects_flag = 0,
constant_flag = 0, addressable_flag = 0, volatile_flag = 0,
readonly_flag = 0, unsigned_flag = 0, asm_written_flag = 0,
nowarning_flag = 0, used_flag = 0, nothrow_flag = 0, static_flag = 0,
public_flag = 0, private_flag = 0, protected_flag = 0,
deprecated_flag = 0, saturating_flag = 0, default_def_flag = 0,
lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0,
lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, visited = 0,
spare = 0, ann = 0x0}, common = {base = {code = IDENTIFIER_NODE,
side_effects_flag = 0, constant_flag = 0, addressable_flag = 0,
volatile_flag = 0, readonly_flag = 0, unsigned_flag = 0,
asm_written_flag = 0, nowarning_flag = 0, used_flag = 0,
nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0,
protected_flag = 0, deprecated_flag = 0, saturating_flag = 0,
default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0,
lang_flag_6 = 0, visited = 0, spare = 0, ann = 0x0}, chain = 0x0,
type = 0x0}, int_cst = {common = {base = {code = IDENTIFIER_NODE,
. . .
imag = 0x12}, identifier = {common = {base = {code = IDENTIFIER_NODE,
side_effects_flag = 0, constant_flag = 0, addressable_flag = 0,
volatile_flag = 0, readonly_flag = 0, unsigned_flag = 0,
asm_written_flag = 0, nowarning_flag = 0, used_flag = 0,
nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0,
protected_flag = 0, deprecated_flag = 0, saturating_flag = 0,
default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0,
lang_flag_6 = 0, visited = 0, spare = 0, ann = 0x0}, chain = 0x0,
type = 0x0}, id = {str = 0x7ff00f20 "unsigned short int", len = 18,
hash_value = 1006702630}}, decl_minimal = {common = {base = {
Not sure yet what's wrong with it or why identifier_global_value is unhappy.
cheers,
DaveK
Re: Invalid reload inheritance with paradoxical subregs
On Wed, Apr 1, 2009 at 3:34 PM, Joern Rennecke wrote:
> I suggest you first find out more what is exactly reloaded and where
> the inheritance occurs - inheritance can be done by choose_reload_regs
> or later in emit_reload_insns and its subfunctions.
>
> I.e. set a breakpoint on find_reloads and make it conditional on
> insn->u.fld[0].rt_int == 121 && replace
> , let the compilation break there, finish, and call debug_reload()
> to look at the scheduled reloads.
> Then set a breakpoint on choose_reload_regs, make it conditional on
> chain->insn->u.fld[0].rt_int == 121
> , continue to the breakpoint, finish, and call debug_reload() again.
> This should tell you what MEM is actually reloaded, and if the inheritance
> already happens there; depending on what you find, you have to look further
> in choose_reload_regs or in the reload emitting code.
Joern,
thans for your detailed instructions. I think I found, where problem is:
Combine simplifies lshiftrt/shift/and combined instruction under the
assumption, that for ZERO_EXTEND LOAD_EXTEND_OP targets it can prove
that certain bits are zero, so AND operation can be omitted. The
resulting instruction is valid only for memory operand:
(gdb) p debug_rtx (insn)
(insn 121 120 125 2 t.c:22 (set (reg:SI 6 r6 [orig:48 y$k.115 ] [48])
(lshiftrt:SI (subreg:SI (mem/s/c:HI (plus:SI (reg/f:SI 1 r1)
(const_int 16 [0x10])) [0+4 S2 A32]) 0)
(const_int 5 [0x5]))) 62 {lshrsi3} (nil))
Now, tracing this instruction through reload_as_needed () function, we
have following reloads just after the call to choose_reload_regs
(...):
(gdb) p debug_reload ()
Reload 0: reload_in (HI) = (mem/s/c:HI (plus:SI (reg/f:SI 1 r1)
(const_int 16
[0x10])) [0+4 S2 A32])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (mem/s/c:HI (plus:SI (reg/f:SI 1 r1)
(const_int 16
[0x10])) [0+4 S2 A32])
reload_reg_rtx: (reg:HI 7 r7)
This is all correct, until subst_reloads (...) is called a coouple of
lines down the source. This call changes (insn 121) to:
(gdb) p debug_rtx (insn)
(insn 121 120 125 2 t.c:22 (set (reg:SI 6 r6 [orig:48 y$k.115 ] [48])
(lshiftrt:SI (subreg:SI (reg:HI 7 r7) 0)
(const_int 5 [0x5]))) 62 {lshrsi3} (nil))
This substitution is wrong. Paradoxical subreg of a memory operand is
for our target known to zero extend to SImode value, however -
paradoxical subreg of a register operand has undefined bits outside
the reg. So, combine and reload doesn't agree on the bits outside the
register.
After this substitution, subreg RTX is simply stripped away via the
call to cleanup_subreg_operands () in reload () and that leaves us
with undefined bits shifted in.
I guess that somehow we have to prevent choose_reload_regs to blindly
substitute memory_operand with register when paradoxical subregs are
involved. The condition for the substitution should be similar to the
condition in nonzero_bits1 from final.c:
#if defined (WORD_REGISTER_OPERATIONS) && defined (LOAD_EXTEND_OP)
/* If this is a typical RISC machine, we only have to worry
about the way loads are extended. */
if ((LOAD_EXTEND_OP (GET_MODE (SUBREG_REG (x))) == SIGN_EXTEND
? (((nonzero
& (((unsigned HOST_WIDE_INT) 1
<< (GET_MODE_BITSIZE (GET_MODE (SUBREG_REG (x))) - 1
!= 0))
: LOAD_EXTEND_OP (GET_MODE (SUBREG_REG (x))) != ZERO_EXTEND)
|| !MEM_P (SUBREG_REG (x)))
#endif
Uros.
[ANNOUNCE] Trunk freeze for alias-improvements branch Fri. Apr. 3rd 8am UTC
The trunk will be frozen for the merge of the alias-improvements branch tomorrow, Friday, April 3rd starting 8am UTC. I will do a last merge to the branch at that point, do a bootstrap & regtest cycle and finally commit the merge to trunk. Thanks for your cooperation. Richard. -- Richard Guenther Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Re: Invalid reload inheritance with paradoxical subregs
On Thu, Apr 02, 2009 at 12:51:55PM +0200, Uros Bizjak wrote: > I guess that somehow we have to prevent choose_reload_regs to blindly > substitute memory_operand with register when paradoxical subregs are > involved. The condition for the substitution should be similar to the > condition in nonzero_bits1 from final.c: Yes. It would be nicer if we could get rid of these special meanings of paradoxical subregs and instead used ZERO_EXTEND and SIGN_EXTEND in their place; this would also give better code for target that can have either of these. However, that would not only require changes to reload to reload these properly, but also to all the affected targets, e.g. rtx_costs would have to discount the cost of the extension operation. This e-mail was sent from a group e-mail system of ARC International Plc. Full details of the registered names and addresses of companies within the ARC group can be found on the ARC website.ARC International plc, Registered Office: Verulam Point, Station WaySt. Albans AL1 5HE United Kingdom Registered in England and Wales No. 3592130savm-exch03
fwprop and CSE const anchor opt
In order for my CSE const anchor patch to work I needed to drastically lower the cost of immediate addition in the MIPS backend. This was acceptable as a proof of concept but not in general of course. The problem is with "single-insn"/simple constants. We would also like these to use const anchors in the hope that the resulting expression would get propagated into MEM expressions. I was hoping that fwprop would do this propagation for me. However, since a single-insn constant load is cheaper than an immediate addition (make sense), fwprop is free to propagate either (1) into (2) or (2) into (3) here: (1) a <- C | +--> (2) b <- a + D || |+--> (3) mem(b) | +--> (4) use(a) Which one it does depends on which one it tries first. Right now we go in insn order so we'd do (1) to (2) preventing to do (2) to (3) later. It seems to me that it would be preferable if fwprop tried propagating into single uses first before trying to propagate into others. This should improve the chances of making more defs redundant. With the example above, (2) would be redundant after propagation. Am I missing something? If this sounds reasonable I can try to work out a patch and see what happens. Adam
Re: generating functions and eh region
> With SEH you can catch that kind of errors and that's why it's so > interesting in embedded world That's also why SEH is a major pain for optimization. The compiler would have to identify every instruction that may trigger an exception, and either treat that instruction as a scheduling boundary or create a new landing pad for the instruction (where compensation code can be placed to adjust for the effects of instructions moved up or down). The former inhibits a lot of optimization, while the latter blows up the size of the EH tables and the corresponding landing pad code. On top of that, the filters can return a code that tells the EH mechanism to resume execution at the original exception point as if nothing happened. Just trying to understand all the implications of that makes my head hurt. -cary
Re: Revised GCC Runtime Library Exception
> The "Compilation Process" transforms code entirely represented in > non-intermediate languages designed for human-written code, > and/or in Java Virtual Machine byte code, into Target Code. Two months for this??? And what about CLR (Mono, .NET) bytecode for example??? Paolo
Re: Call for testers: MPC-0.6 released
From: "Marc Glisse" This could be related to a call to sprintf(str,...,str,...), which according to the doc is undefined behaviour. Doc? I don't see it in the man page. Got a url?
Re: Call for testers: MPC-0.6 released
On Thu, Apr 02, 2009 at 01:55:29PM -0700, Kaveh R. Ghazi wrote: > From: "Marc Glisse" > >This could be related to a call to sprintf(str,...,str,...), which > >according to the doc is undefined behaviour. > > Doc? I don't see it in the man page. Got a url? man 3p sprintf says: If copying takes place between objects that overlap as a result of a call to sprintf() or snprintf(), the results are undefined. ISO C99 7.19.6.6 has similar wording: If copying takes place between objects that overlap, the behavior is undefined. Jakub
Re: Call for testers: MPC-0.6 released
From: "Jakub Jelinek" man 3p sprintf says: If copying takes place between objects that overlap as a result of a call to sprintf() or snprintf(), the results are undefined. ISO C99 7.19.6.6 has similar wording: If copying takes place between objects that overlap, the behavior is undefined. Jakub Thanks for the details. (BTW, there's no 3p section on my linux box, and man 3 sprintf doesn't mention the undefined-ness. So thanks for the C99 reference.) --Kaveh
Re: Call for testers: MPC-0.6 released
From: "Janis Johnson" I get the failure Richard mentioned when I use -D_FORTIFY_SOURCE=2 -fstack-protector but no failures without those options. This is on powerpc64-linux (but defaulting to -m32) with: RHEL 5.3 GCC 4.3.2 GMP 4.2.4 MPFR 2.4.1 MPC 0.6 Okay the -D_FORTIFY_SOURCE=2 bug has been fixed in svn. I don't think that affects any platform besides linux when using that macro. So we can proceed with testing mpc-0.6 on other platforms. We still need to complete the primary/secondary list missing from this link for mpc-0.6: http://www.multiprecision.org/mpc/index.php?content=platforms I.e. we need (primaries) x86-freebsd, x86-darwin, sparc-solaris2.10 and (secondaries) hppa-hpux11, ppc-aix5.2, ppc-darwin, x86-mingw32 and s390-linux-gnu. If you supplied the relevant testing for the prerelease tarball svn459, if you would be so kind as to repeat the testing with the official mpc-0.6 release I would greatly appreciate it. (Thanks Ralf!) Get it here: http://www.multiprecision.org/mpc/ And report your results along with the versions of target triplet/compiler/gmp/mpfr that you used. I've cc'ed others who have access to the platforms in question based on GCC test results. Please help if you can. Thanks, --Kaveh
gcc-4.5-20090402 is now available
Snapshot gcc-4.5-20090402 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090402/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 145482 You'll find: gcc-4.5-20090402.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20090402.tar.bz2 C front end and core compiler gcc-ada-4.5-20090402.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20090402.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20090402.tar.bz2 C++ front end and runtime gcc-java-4.5-20090402.tar.bz2 Java front end and runtime gcc-objc-4.5-20090402.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20090402.tar.bz2The GCC testsuite Diffs from 4.5-20090327 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
