Re: Unwinding CFI gcc practice of assumed `same value' regs
Jan Kratochvil writes: > currently (on x86_64) the gdb backtrace does not properly stop at > the outermost frame: > > #3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0 > #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6 > #5 0x in ?? () > > Currently it relies only on clearing %rbp (0x above is > unrelated to it, it got read from uninitialized memory). That's how it's defined to work: %rbp is zero. > http://sourceware.org/ml/gdb/2004-08/msg00060.html suggests frame > pointer 0x0 should be enough for a debugger not finding CFI to stop > unwinding, still it is a heuristic. Not by my understanding it isn't. It's set up by the runtime system, and 0 (i.e. NULL on x86-64) marks the end of the stack. Officially. See page 28, AMD64 ABI Draft 0.98 \u2013 September 27, 2006 -- 9:24. Andrew.
Re: Unwinding CFI gcc practice of assumed `same value' regs
> Jan Kratochvil writes: > > > currently (on x86_64) the gdb backtrace does not properly stop at > > the outermost frame: > > > > #3 0x0036ddb0610a in start_thread () from > /lib64/tls/libpthread.so.0 > > #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6 > > #5 0x in ?? () > > > > Currently it relies only on clearing %rbp (0x above is > > unrelated to it, it got read from uninitialized memory). > > That's how it's defined to work: %rbp is zero. > > > http://sourceware.org/ml/gdb/2004-08/msg00060.html suggests frame > > pointer 0x0 should be enough for a debugger not finding CFI to stop > > unwinding, still it is a heuristic. > > Not by my understanding it isn't. It's set up by the runtime system, > and 0 (i.e. NULL on x86-64) marks the end of the stack. Officially. > > See page 28, AMD64 ABI Draft 0.98 \u2013 September 27, 2006 -- 9:24. Unfortunately whoever wrote that down didn't think it through. In Figure 3.4 on page 20, %rbp is listed as "callee-saved register; optionally used as frame pointer". So %rbp can be used for anything, as long as you save its contents and restore it before you return. Since it may be used for anything, it may contain 0 at any point in the middle of the call stack. So it is unusable as a stack trace termination condition. The only viable option is explicitly marking it as such in the CFI. Initializing %rbp to 0 in the outermost frame is sort of pointless on amd64.
Re: Unwinding CFI gcc practice of assumed `same value' regs
Mark Kettenis writes: > > Jan Kratochvil writes: > > > > > currently (on x86_64) the gdb backtrace does not properly stop at > > > the outermost frame: > > > > > > #3 0x0036ddb0610a in start_thread () from > > /lib64/tls/libpthread.so.0 > > > #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6 > > > #5 0x in ?? () > > > > > > Currently it relies only on clearing %rbp (0x above is > > > unrelated to it, it got read from uninitialized memory). > > > > That's how it's defined to work: %rbp is zero. > > > > > http://sourceware.org/ml/gdb/2004-08/msg00060.html suggests frame > > > pointer 0x0 should be enough for a debugger not finding CFI to stop > > > unwinding, still it is a heuristic. > > > > Not by my understanding it isn't. It's set up by the runtime system, > > and 0 (i.e. NULL on x86-64) marks the end of the stack. Officially. > > > > See page 28, AMD64 ABI Draft 0.98 \u2013 September 27, 2006 -- 9:24. > > Unfortunately whoever wrote that down didn't think it through. In > Figure 3.4 on page 20, %rbp is listed as "callee-saved register; > optionally used as frame pointer". So %rbp can be used for anything, as > long as you save its contents and restore it before you return. Null-terminating the call stack is too well-established practice to be changed now. In practice, %ebp either points to a call frame -- not necessarily the most recent one -- or is null. I don't think that having an optional frame pointer mees you can use %ebp for anything random at all, but we need to make a clarification request of the ABI. > Since it may be used for anything, it may contain 0 at any point in > the middle of the call stack. > So it is unusable as a stack trace termination condition. The only > viable option is explicitly marking it as such in the CFI. > > Initializing %rbp to 0 in the outermost frame is sort of pointless > on amd64. The right way to fix the ABI is to specify that %ebp mustn't be [mis]used in this way, not to add a bunch more unwinder data. Andrew.
Re: Unwinding CFI gcc practice of assumed `same value' regs
Andrew Haley wrote: Null-terminating the call stack is too well-established practice to be changed now. Which does not mean that the mistake should hold people back. This is just one of the mistakes in the x86-64 ABI. It was copied from x86 and it was wrong there already. In practice, %ebp either points to a call frame -- not necessarily the most recent one -- or is null. I don't think that having an optional frame pointer mees you can use %ebp for anything random at all, Of course it means that. The right way to fix the ABI is to specify that %ebp mustn't be [mis]used in this way, not to add a bunch more unwinder data. Nope. The right way is to specify things like backtraces with the adequate mechanism. I fully support adding the Dwarf3 unwinder requirements. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Re: Unwinding CFI gcc practice of assumed `same value' regs
Ulrich Drepper writes: > Andrew Haley wrote: > > Null-terminating the call stack is too well-established practice to be > > changed now. > > Which does not mean that the mistake should hold people back. Sure it does. Not breaking things is an excellent reason, probably one of the the best reasons you can have. > This is just one of the mistakes in the x86-64 ABI. It was copied > from x86 and it was wrong there already. > > > In practice, %ebp either points to a call frame -- not necessarily the > > most recent one -- or is null. I don't think that having an optional > > frame pointer mees you can use %ebp for anything random at all, > > Of course it means that. Really? Well, that's one interpretation. I don't believe that, though. It's certainly an inconsistency in the specification, which says that null-termination is supported, and this implies that you can't put a zero in there. > > The right way to fix the ABI is to specify that %ebp mustn't be > > [mis]used in this way, not to add a bunch more unwinder data. > > Nope. The right way is to specify things like backtraces with the > adequate mechanism. I fully support adding the Dwarf3 unwinder > requirements. "All of these" might be the right way to go. That is, keep null-terminating the stack, strengthen the rules about what you might do with %ebp, and extend debuginfo. Andrew.
Re: Unwinding CFI gcc practice of assumed `same value' regs
Andrew Haley wrote: Sure it does. Not breaking things is an excellent reason, probably one of the the best reasons you can have. Nothing breaks if the responsible tools are updated in unison. Really? Well, that's one interpretation. I don't believe that, though. It's certainly an inconsistency in the specification, which says that null-termination is supported, and this implies that you can't put a zero in there. Again, this is just because the "authors" of the ABI didn't think. x86 has the same problem. ebp is freely used and not just for non-NULL values. Register's a scarce and I doubt you'll find any support introducing a register class which says that the register can only hold non-zero value. "All of these" might be the right way to go. That is, keep null-terminating the stack, strengthen the rules about what you might do with %ebp, and extend debuginfo. The thread setup and the startup code certainly does initialize the register with zero. But this means nothing, the register can have zero values in all kinds of other places. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Re: Unwinding CFI gcc practice of assumed `same value' regs
On Tue, 12 Dec 2006 16:26:34 +0100, Andrew Haley wrote:
...
> It's certainly an inconsistency in the specification, which says that
> null-termination is supported, and this implies that you can't put a zero in
> there.
I tested now that you can put the zero there for both the libgcc unwinder and
for gdb(1) [tested only Fedora Core gdb-6.5-13.fc6],
attached, on x86_64 compile [gcc-4.1.1-30] and run by:
gcc -o fp0-x86_64 -O9 -fomit-frame-pointer -Wall fp0-x86_64.c -ggdb3;
./fp0-x86_64
The output provided at the end of this mail.
Therefore I believe this sentence is wrong and it should be removed:
http://www.x86-64.org/documentation/abi.pdf (draft 0.98) Page 28
(29/124)
%rbp ... but the user code should mark the deepest stack frame by
%setting the frame pointer to zero.
On the other hand the right stack terminator for libgcc unwinder is `PC == 0':
unwind-dw2.c:uw_frame_state_for ():
if (context->ra == 0)
return _URC_END_OF_STACK;
And gdb should just get updated to behave the same way.
libunwind already assumed end of stack on `PC == 0' before and I do not expect
any platform would consider `PC == 0' as a valid _return_address_ (which is
usually several bytes after any starting function address due to the call
instruction).
...
> "All of these" might be the right way to go. That is, keep
> null-terminating the stack, strengthen the rules about what you might
> do with %ebp, and extend debuginfo.
For best compatibility null terminate the stack but by CFI and its indicated
return address. Do not use %rbp (frame pointer register) in any way (regarding
the stack termination condition).
Believe only CFI-specified CFA address, unrelated to %rbp content.
Regards,
Jan
--
GNU gdb Red Hat Linux (6.5-13.fc6rh)
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db
library "/lib64/libthread_db.so.1".
(gdb) b 12
Breakpoint 1 at 0x40060b: file fp0-x86_64.c, line 12.
(gdb) r
Starting program: /root/jkratoch/redhat/unwind/fp0-x86_64
Breakpoint 1, backtracer () at fp0-x86_64.c:12
12 int i = backtrace (buf, 512);
(gdb) bt
#0 backtracer () at fp0-x86_64.c:12
#1 0x00400739 in badone () at fp0-x86_64.c:31
#2 0x0040074e in main () at fp0-x86_64.c:47
(gdb) p/x $rbp
$1 = 0x7fff6ed61ca0
(gdb) up
#1 0x00400739 in badone () at fp0-x86_64.c:31
31 backtracer ();
(gdb) p/x $rbp
$2 = 0x0
(gdb) c
Continuing.
dummy
5
/root/jkratoch/redhat/unwind/fp0-x86_64[0x40062c]
/root/jkratoch/redhat/unwind/fp0-x86_64[0x400739]
/root/jkratoch/redhat/unwind/fp0-x86_64[0x40074e]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x301e81da44]
/root/jkratoch/redhat/unwind/fp0-x86_64[0x400559]
Program received signal SIGSEGV, Segmentation fault.
0x00400684 in backtracer () at fp0-x86_64.c:21
21 RAFA(1);
(gdb) q
#include
#include
#include
#include
static void backtracer (void) __attribute__((__noinline__));
static void backtracer (void)
{
void *buf[512];
puts("dummy");
int i = backtrace (buf, 512);
printf ("%d\n", i);
fflush (stdout);
backtrace_symbols_fd (buf, i, STDOUT_FILENO);
#define RAFA(level) \
printf("RA (%d) = %p, FA (%d) = %p\n", \
level, __builtin_return_address (level), \
level, __builtin_frame_address (level))
RAFA(0);
RAFA(1);
RAFA(2);
RAFA(3);
RAFA(4);
RAFA(5);
}
static int badone (void) __attribute__((__noinline__));
static int badone (void)
{
backtracer ();
return 0;
}
asm(
" .text \n"
"clearstack:\n"
" pushq $0 \n"
" popq%rax\n"
" ret \n"
);
extern void clearstack(void);
int main (void)
{
clearstack ();
badone ();
return 0;
}
Re: Unwinding CFI gcc practice of assumed `same value' regs
On Mon, Dec 11, 2006 at 02:40:22PM -0800, Roland McGrath wrote:
> My reading is that the "ABI authoring body" for GNU systems or the
> "compilation system authoring body" for GNU compilers already specifies
> that the default rule is same_value for callee-saves registers (as chosen
> by each particular ABI), even if this has not been formally documented
> anywhere heretofore. (This is how I've written ABI support in another
> unwinder implementation I've worked on.) As you've said, this is the only
> reading by which current CFI is correct and complete for getting the values
> of callee-saves registers. I presume that GCC's omission of rules for
> those registers is in fact simply because EH unwinding doesn't care and
> people on the generation side just didn't think about it beyond that.
> Regardless of the true reasons for the history, the description above
> applies to the manifest practice that constitutes what we want the formal
> specification to mean.
Well, for satisfying the requirement that undefined retaddr_column
identifies outermost frame it matters whether retaddr_column's default rule
is same_value or undefined. If it is by default same_value, then
unwind-dw2.c should just handle explicit DW_CFA_undefined retaddr_column
as outermost frame mark, otherwise it would need to handle any unspecified
or explicit DW_CFA_undefined retaddr_column (but not DW_CFA_same_value).
Here is something that would handle by default same_value retaddr_column:
--- gcc/unwind-dw2.h2006-10-29 21:49:23.0 +0100
+++ gcc/unwind-dw2.h2006-12-12 16:30:29.0 +0100
@@ -1,5 +1,5 @@
/* DWARF2 frame unwind data structure.
- Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003
+ Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2006
Free Software Foundation, Inc.
This file is part of GCC.
@@ -55,7 +55,8 @@ typedef struct
REG_SAVED_REG,
REG_SAVED_EXP,
REG_SAVED_VAL_OFFSET,
- REG_SAVED_VAL_EXP
+ REG_SAVED_VAL_EXP,
+ REG_UNDEFINED
} how;
} reg[DWARF_FRAME_REGISTERS+1];
--- gcc/unwind-dw2.c2006-12-08 15:57:44.0 +0100
+++ gcc/unwind-dw2.c2006-12-12 16:38:26.0 +0100
@@ -887,12 +887,16 @@ execute_cfa_program (const unsigned char
fs->regs.reg[DWARF_REG_TO_UNWIND_COLUMN(reg)].how = REG_UNSAVED;
break;
- case DW_CFA_undefined:
case DW_CFA_same_value:
insn_ptr = read_uleb128 (insn_ptr, ®);
fs->regs.reg[DWARF_REG_TO_UNWIND_COLUMN(reg)].how = REG_UNSAVED;
break;
+ case DW_CFA_undefined:
+ insn_ptr = read_uleb128 (insn_ptr, ®);
+ fs->regs.reg[DWARF_REG_TO_UNWIND_COLUMN(reg)].how = REG_UNDEFINED;
+ break;
+
case DW_CFA_nop:
break;
@@ -1255,6 +1259,7 @@ uw_update_context_1 (struct _Unwind_Cont
switch (fs->regs.reg[i].how)
{
case REG_UNSAVED:
+ case REG_UNDEFINED:
break;
case REG_SAVED_OFFSET:
@@ -1323,10 +1328,21 @@ uw_update_context (struct _Unwind_Contex
{
uw_update_context_1 (context, fs);
- /* Compute the return address now, since the return address column
- can change from frame to frame. */
- context->ra = __builtin_extract_return_addr
-(_Unwind_GetPtr (context, fs->retaddr_column));
+ /* In general this unwinder doesn't make any distinction between
+ undefined and same_value rule. Call-saved registers are assumed
+ to have same_value rule by default and explicit undefined
+ rule is handled like same_value. The only exception is
+ DW_CFA_undefined on retaddr_column which is supposed to
+ mark outermost frame in DWARF 3. */
+ if (fs->regs[fs->retaddr_column].how == REG_UNDEFINED)
+/* uw_frame_state_for uses context->ra == 0 check to find outermost
+ stack frame. */
+context->ra = 0;
+ else
+/* Compute the return address now, since the return address column
+ can change from frame to frame. */
+context->ra = __builtin_extract_return_addr
+ (_Unwind_GetPtr (context, fs->retaddr_column));
}
static void
Jakub
Re: Unwinding CFI gcc practice of assumed `same value' regs
On Tue, Dec 12, 2006 at 03:26:34PM +, Andrew Haley wrote: > Ulrich Drepper writes: > > Andrew Haley wrote: > > > Null-terminating the call stack is too well-established practice to be > > > changed now. > > > > Which does not mean that the mistake should hold people back. > > Sure it does. Not breaking things is an excellent reason, probably > one of the the best reasons you can have. Well, libgcc unwinder handles neither %rbp 0 termination (even if that would be rephrased as outermost frame on x86-64 is determined by %rbp == 0 if CFA is %rbp + offset (that would handle the -fomit-frame-pointer routines where CFA is %rsp + offset)), nor DW_CFA_undefined %rip termination ATM. Things worked until now simply because the outermost routine (_start resp. thread_start hunk in clone in glibc) so far didn't have any unwind info. What would work with stock libgcc unwinder would probably be if _start or clone's child hunk had %rip point to memory containing 0 or DW_CFA_val_expression returning 0 (well, on SPARC that would need to be -8, as RETURN_ADDR_OFFSET is added to it). Jakub
Re: Unwinding CFI gcc practice of assumed `same value' regs
Andrew Haley <[EMAIL PROTECTED]> writes: > In practice, %ebp either points to a call frame -- not necessarily the > most recent one -- or is null. I don't think that having an optional > frame pointer mees you can use %ebp for anything random at all, but we > need to make a clarification request of the ABI. I don't see that as feasible. If %ebp/%rbp may be used as a general callee-saved register, then it can hold any value. And permitting %ebp/%rbp to hold any value is a very useful optimization in a function which does not require a frame pointer, since it gives the compiler an extra register to use. If you want to require %ebp/%rbp to hold a non-zero value, then you are effectively saying that this optimization is forbidden. There is no meaningful way to tell gcc "this is a general register, but you may not store zero in it." It would be a poor tradeoff to forbid that optimization in order to provide better support for exception handling: exception handling is supposed to be unusual. Ian
Re: Unwinding CFI gcc practice of assumed `same value' regs
Ian Lance Taylor writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > In practice, %ebp either points to a call frame -- not necessarily the > > most recent one -- or is null. I don't think that having an optional > > frame pointer mees you can use %ebp for anything random at all, but we > > need to make a clarification request of the ABI. > > I don't see that as feasible. If %ebp/%rbp may be used as a general > callee-saved register, then it can hold any value. Sure, we already know that, as has been clear. The question is *if* %rbp may be used as a general callee-saved register that can hold any value. > And permitting %ebp/%rbp to hold any value is a very useful > optimization in a function which does not require a frame pointer, > since it gives the compiler an extra register to use. > > If you want to require %ebp/%rbp to hold a non-zero value, then you > are effectively saying that this optimization is forbidden. There is > no meaningful way to tell gcc "this is a general register, but you may > not store zero in it." It would be a poor tradeoff to forbid that > optimization in order to provide better support for exception > handling: exception handling is supposed to be unusual. Sure, that's reasonable: it's a good reason to suggest that the ABI spec (still in DRAFT state, I note!) might be changed. Andrew.
Re: Unwinding CFI gcc practice of assumed `same value' regs
> Ian Lance Taylor writes: > > Andrew Haley <[EMAIL PROTECTED]> writes: > > > > > In practice, %ebp either points to a call frame -- not necessarily > the > > > most recent one -- or is null. I don't think that having an optional > > > frame pointer mees you can use %ebp for anything random at all, but > we > > > need to make a clarification request of the ABI. > > > > I don't see that as feasible. If %ebp/%rbp may be used as a general > > callee-saved register, then it can hold any value. > > Sure, we already know that, as has been clear. The question is *if* > %rbp may be used as a general callee-saved register that can hold any > value. The amd64 ABI is specifically *designed* to allow this. Mark
gcc-4.2-20061212 is now available
Snapshot gcc-4.2-20061212 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20061212/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 119792 You'll find: gcc-4.2-20061212.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20061212.tar.bz2 C front end and core compiler gcc-ada-4.2-20061212.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20061212.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20061212.tar.bz2 C++ front end and runtime gcc-java-4.2-20061212.tar.bz2 Java front end and runtime gcc-objc-4.2-20061212.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20061212.tar.bz2The GCC testsuite Diffs from 4.2-20061205 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
Re: [PATCH] Relocated compiler should not look in $prefix.
Andrew Pinski wrote: > On Fri, 2006-10-13 at 12:51 -0400, Carlos O'Donell wrote: >> A relocated compiler should not look in $prefix. >> Comments? >> OK for Stage1? > > I do have another issue with these set of patches which I did not notice > until today. > I can no longer do inside a just built GCC do: > ./cc1 t.c > or > ./xgcc -B. t.c > If I used the same prefix of an already installed GCC. > This makes debugging driver issues without installing the driver again. What are the contents of t.c? What if you set GCC_EXEC_PREFIX? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Profiling broken in GCC 4.1.0 for DJGPP
I've come across an issue with using the -pg switch for profiling on the DJGPP DOS platform, using GCC 4.1.0. After some digging through disassembly, I found that the part of the function prologue for main() before the call to mcount() is using the ECX register, and the call to the mcount() function appears to be clobbering it. I've verified that GCC 4.1.0 for Linux appears to work, and GCC 4.0.1 for DJGPP also works fine. Here's the assembly for the function prologue of main(): lea0x4(%esp),%ecx and$0xfff0,%esp pushl 0xfffc(%ecx) push %ebp mov%esp,%ebp push %ebx push %ecx mov$0x146e0,%edx call 0x3890 mov%ecx,%ebx <--- clobbered value of ECX is used And here's the relevant portion of mcount(): push %ebp mov%esp,%ebp push %edi push %esi push %ebx sub$0x1c,%esp mov%edx,0xffec(%ebp) mov0x15ca0,%ecx <--- ECX gets clobbered So I'm trying to figure out what's changed; is there a new requirement that ECX is not preserved that didn't exist before? I've looked through some GCC source but I'm really not at all sure what I should be looking for. TIA...
Re: 32bit Calling conventions on linux/ppc.
> Joslwah writes: Joslwah> Looking at the Linux 32bit PowerPC ABI spec, it appears to me that Joslwah> floats in excess of those that are passed in registers are supposed to Joslwah> be promoted to doubles and passed on the stack. Examing the resulting Joslwah> stack from a gcc generated C call it appears they are passed as Joslwah> floats. Joslwah> Can someone confirm/refute this, or else point me to an ABI that says Joslwah> that they should be passed as floats. I have not been able to find any motivation for promoting floats passed ont the stack. Does this provide some form of compatibility with SPARC? David
Re: 32bit Calling conventions on linux/ppc.
On Dec 12, 2006, at 11:42 AM, David Edelsohn wrote: Joslwah writes: Joslwah> Looking at the Linux 32bit PowerPC ABI spec, it appears to me that Joslwah> floats in excess of those that are passed in registers are supposed to Joslwah> be promoted to doubles and passed on the stack. Examing the resulting Joslwah> stack from a gcc generated C call it appears they are passed as Joslwah> floats. Joslwah> Can someone confirm/refute this, or else point me to an ABI that says Joslwah> that they should be passed as floats. I have not been able to find any motivation for promoting floats passed ont the stack. Does this provide some form of compatibility with SPARC? It may have been intended to allow the callee to be a K&R-style or varargs function, where all float args get promoted to double. In particular, printf was often called without being declared in K&R- era code. This is one way to make that code work in a C90 environment.
Re: 32bit Calling conventions on linux/ppc.
> Dale Johannesen writes: Dale> It may have been intended to allow the callee to be a K&R-style or Dale> varargs function, where all float args get promoted to double. Dale> In particular, printf was often called without being declared in K&R- Dale> era code. This is one way to make that code work in a C90 environment. Except that arguments in registers are not promoted and arguments in registers spilled to the stack for varargs are not promoted. In fact it makes varargs more complicated. And it does not really match K&R promotion rules. David
Re: 32bit Calling conventions on linux/ppc.
On Dec 12, 2006, at 12:07 PM, David Edelsohn wrote: Dale Johannesen writes: Dale> It may have been intended to allow the callee to be a K&R- style or Dale> varargs function, where all float args get promoted to double. Dale> In particular, printf was often called without being declared in K&R- Dale> era code. This is one way to make that code work in a C90 environment. Except that arguments in registers are not promoted and arguments in registers spilled to the stack for varargs are not promoted. In fact it makes varargs more complicated. And it does not really match K&R promotion rules. On ppc, floating point regs always contain values in double format, so passing a single value and reading it as double Just Works. To clarify, I am not defending this, just offering a possible explanation. If I'm right, the whole issue is obsolete and there is currently no good reason to do the promotion.
Re: [PATCH] Relocated compiler should not look in $prefix.
What are the contents of t.c? What if you set GCC_EXEC_PREFIX?
t.c:
#include
int main(void)
{
printf("Hello World\n");
return 0;
}
--
No I did not set GCC_EXEC_PREFIX as I did not know I have to set that now.
Seems like a change like this should be mentioned on
http://gcc.gnu.org/gcc-4.3/changes.html
Because some people liked the old behavior when debugging the driver.
Thanks,
Andrew Pinski
Re: [PATCH] Relocated compiler should not look in $prefix.
Andrew Pinski wrote:
>> What are the contents of t.c? What if you set GCC_EXEC_PREFIX?
>
> t.c:
>
> #include
> int main(void)
> {
> printf("Hello World\n");
> return 0;
> }
>
> --
> No I did not set GCC_EXEC_PREFIX as I did not know I have to set that now.
> Seems like a change like this should be mentioned on
> http://gcc.gnu.org/gcc-4.3/changes.html
> Because some people liked the old behavior when debugging the driver.
This not a user-visible change; it does not affect installed compilers.
It only affects GCC developers who are working with the uninstalled driver.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: [PATCH] Relocated compiler should not look in $prefix.
>
> Andrew Pinski wrote:
> >> What are the contents of t.c? What if you set GCC_EXEC_PREFIX?
> >
> > t.c:
> >
> > #include
> > int main(void)
> > {
> > printf("Hello World\n");
> > return 0;
> > }
> >
> > --
> > No I did not set GCC_EXEC_PREFIX as I did not know I have to set that now.
> > Seems like a change like this should be mentioned on
> > http://gcc.gnu.org/gcc-4.3/changes.html
> > Because some people liked the old behavior when debugging the driver.
>
> This not a user-visible change; it does not affect installed compilers.
> It only affects GCC developers who are working with the uninstalled driver.
But other non user-visible changes are mentioned on changes.html already.
Forward prop in 4.3.
Incompatible changes to the build system in 4.2 which seems very related to
stuff like
this.
-- Pinski
Re: [PATCH] Relocated compiler should not look in $prefix.
Andrew Pinski wrote: > But other non user-visible changes are mentioned on changes.html already. > Forward prop in 4.3. > Incompatible changes to the build system in 4.2 which seems very related to > stuff like > this. If you want to make a patch, and Gerald approves it, it's fine by me. But, fwprop is described as a new feature (faster compiler, better code), and the build system affects people building the compiler. The change we're talking about seems to affect only people debugging the compiler. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: 32 bit jump instruction.
On 06 Dec 2006 23:13:35 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: David Daney <[EMAIL PROTECTED]> writes: > > I am working on a private target where jump instruction patterns are > > similiar to this > > > > jmp <24 bit offset> > > jmp for 32 bit offsets > > > > if my offset is greater than 24 bits, then i have to move the offset > > to an address register. But inside the branch instruction (in md > > file), i am not able to generate a pseudo register because the > > condition check for "no_new_pseudos " fails. > > > > Can any one suggest a way to overcome this? > > > This is similar to how the MIPS works. Perhaps looking at its > implementation would be useful. MIPS simply reserves a register, $1. $1 is by convention reserved for use in assembler code. gcc uses it for a long branch. I have done this. It works perfectly. But i cannot afford to lose a register. If you can't afford to lose a register, then I think your only option is to pick some callee-saved register and have each branch instruction explicitly clobber it. Then it will be available for use in a long branch, and it will be available for use within a basic block. This is far from ideal, but I don't know a better way to handle it within gcc's current framework. Can i get more clarity on this part. Is it implemented in any other backends? When you say "pick some callee-saved register ", is it to pick them randomly from an available set in CALL_USED_REGISTERS or a specific register. Ian Regards, Rohit
Re: 32 bit jump instruction.
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes: > > If you can't afford to lose a register, then I think your only option > > is to pick some callee-saved register and have each branch instruction > > explicitly clobber it. Then it will be available for use in a long > > branch, and it will be available for use within a basic block. This > > is far from ideal, but I don't know a better way to handle it within > > gcc's current framework. > > Can i get more clarity on this part. Is it implemented in any other backends? Not to my knowledge. > When you say "pick some callee-saved register ", is it to pick them > randomly from an available set in CALL_USED_REGISTERS or a specific > register. Well, it would be a lot easier if you use a specific register. Then you can just add a CLOBBER to the branch pattern in the MD file. Assuming your callee-saved registers are more or less equivalent, there wouldn't be any advantage to letting the compiler choose one. Ian
