Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
Found it, finally. powerpc ld --relax had a bug affecting -fPIC code. See http://sourceware.org/ml/binutils/2008-08/msg00040.html -- Alan Modra Australia Development Lab, IBM
Re: gcc will become the best optimizing x86 compiler -> PPC case
---Andrew Pinski <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote:
> > The PPC has a very fast dcbz (data cache block zero) to clear memory,
> > and also dcbi (data cache block invalidate) which permit to have a
> > cached line caching an address without reading first the memory (when
> > you plan to write the whole line).
> > The code in opensolaris.org doesn't seem to handle that.
>
> Except dcbz does not work for caching-inhibited memory (as it will
> cause an alignment exception) so ...
Just for info, I redone the test to clear/preset and test 256 Mbytes
of memory on this proprietary PPC target (at boot time):
- memset take 1172 ms, memset code is basically:
unsigned val = ch;
val |= (val << 8);
val |= (val << 16);
len /= 4;
dst = (void *)((unsigned)dst - sizeof (unsigned));
asm volatile (" 1: stu %2,4(%0) ; bdnz+1b "
: "+b" (dst), "+c" (len) : "r" (val) : "memory" );
// bdnz+ or bdnz- or bdnz gives same execution time
- processor internal DMA writing to 256 Mbytes: 657 ms
- clearing the memory by dcbz: 154 ms
Reading/testing the 256 Mbytes is 720 ms.
The very short time of dcbz may worth a cache test for bzero(), on PPC a
tlbsx / tlbre should be enough (if the whole range of memory does not
need to be tested) - Intel is another story (and it is probably best
there to do it inside the processor: when ecx big enough on a rep, each
transfer should be a full cache line to stop reading the data to
overwrite).
Etienne.
_
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
RE: --sysroot=yes
With a little more cross building experience...I'm still convinced there is a
problem here.
Canadian cross doesn't do the right thing in fixincludes.
There are remnants of a fix in the 4.3.1 configure.ac here:
# When building gcc with a cross-compiler, we need to adjust things so
# that the generator programs are still built with the native compiler.
# Also, we cannot run fixincludes or fix-header.
# These are the normal (build=host) settings:
CC_FOR_BUILD='$(CC)'AC_SUBST(CC_FOR_BUILD)
BUILD_CFLAGS='$(ALL_CFLAGS)'AC_SUBST(BUILD_CFLAGS)
STMP_FIXINC=stmp-fixinc AC_SUBST(STMP_FIXINC)
# Possibly disable fixproto, on a per-target basis.
case ${use_fixproto} in
no)
STMP_FIXPROTO=
;;
yes)
STMP_FIXPROTO=stmp-fixproto
;;
esac
AC_SUBST(STMP_FIXPROTO)
# And these apply if build != host, or we are generating coverage data
if test x$build != x$host || test "x$coverage_flags" != x
then
BUILD_CFLAGS='$(INTERNAL_CFLAGS) $(T_CFLAGS) $(CFLAGS_FOR_BUILD)'
if test "x$TARGET_SYSTEM_ROOT" = x; then
if test "x$STMP_FIXPROTO" != x; then
STMP_FIXPROTO=stmp-install-fixproto
fi
fi
fi
but it doesn't work. The above code is basically the same in trunk.
fix-includes still runs and uses the build headers instead of the target
headers.
-with-build-sysroot doesn't workaround because:
if test x$host != x$target
then
CROSS="-DCROSS_DIRECTORY_STRUCTURE"
ALL=all.cross
SYSTEM_HEADER_DIR=$build_system_header_dir
case "$host","$target" in
# Darwin crosses can use the host system's libraries and headers,
# because of the fat library support. Of course, it must be the
# same version of Darwin on both sides. Allow the user to
# just say --target=foo-darwin without a version number to mean
# "the version on this system".
*-*-darwin*,*-*-darwin*)
hostos=`echo $host | sed 's/.*-darwin/darwin/'`
targetos=`echo $target | sed 's/.*-darwin/darwin/'`
if test $hostos = $targetos -o $targetos = darwin ; then
CROSS=
SYSTEM_HEADER_DIR='$(NATIVE_SYSTEM_HEADER_DIR)'
with_headers=yes
fi
;;
i?86-*-*,x86_64-*-* \
| powerpc*-*-*,powerpc64*-*-*)
CROSS="$CROSS -DNATIVE_CROSS" ;;
esac
elif test "x$TARGET_SYSTEM_ROOT" != x; then
SYSTEM_HEADER_DIR=$build_system_header_dir
fi
goes down the native path. Also same in trunk.
Oh, maybe I should do that thing where you make up a platform?
(I saw this in "Do-it-yourself Linux" similar to Linux-from-Scratch").
-host sparc-foo-solaris2.10 -target sparc-sun-solaris2.10
instead of:
-host sparc-sun-solaris2.10 -target sparc-sun-solaris2.10
?
That feels wrong..
Hm, am I supposed to run mkheaders after install? <<<
Ah, I guess so.
But still the above appears in need of repair.
And if user gives -with-build-sysroot, then fixincludes can be run
on the build machine in a Canadian cross.
I opened a bug, but it doesn't have all this info (yet).
- Jay
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: gcc@gcc.gnu.org
> Subject: RE: --sysroot=yes
> Date: Sat, 26 Jul 2008 08:12:14 +
>
>
> Joseph, Right, I read that in the docs and I understand.
> As well, this is probably unusual enough, that no default is needed?
>
> Do you agree, at least, that fixincludes has a bug here?
>
> For now I am working around by using -with-build-sysroot=/usr/local//sys-root.
> which is redundant but ok for compiling and linking, since the build=>target
> toolset in use
> was already configured with -with-sysroot. I expect it will fix fixincludes
> though.
> After all, fixincludes worked when building the buld=>target tools.
>
> The diff had at least one error, an extraneous ";;".
>
> I *really* think there's a bug here.
> But I agree the diff I sent is not necessarily the fix.
>
> 1) -with-build-sysroot should complain clearly and early if not given a
> parameter
> That is, if the parameter is "yes".
> (Autoconf should probably have a way to indicate a parameter is required, if
> it doesn't already.)
>
> 2) More importantly, fixincludes doesn't get the right headers in this
> scenario (Canadian cross?
> "crossing to native"? I think Canadian cross is not "there are three
> platforms", but that build != host,
> and there /might/ be three platforms. I think three platforms implies
> Canadian cross, but two can also?
> I understand the general picture, of build/host/target, just not what to call
> things "for short".)
>
> There is already a build=>target toolset that knows where to get files.
> Maybe fixincludes should be part of that?
> Well, actually, it is, but that isn't sufficient.
> It is the Makefile that is driving it that is "confused".
> A possible fix would be to "configure" fixinc.sh with defaults??
> No, that seems wrong. At least to include
Re: Problem reading corefiles on ARM
> Date: Wed, 6 Aug 2008 11:27:36 -0400 > From: Daniel Jacobowitz <[EMAIL PROTECTED]> > > On Wed, Aug 06, 2008 at 07:19:26PM +0400, Sergei Poselenov wrote: > > (gdb) bt > > #0 0x4004ec0c in raise () from /lib/libc.so.6 > > #1 0x40050234 in abort () from /lib/libc.so.6 > > Backtrace stopped: frame did not save the PC > > Your implementation of abort does not save a return address, so GDB > can't display it. I believe tehis is a known limitation of the ARM > GCC port. GCC should really not do this. People are almost guaranteed to want to be able to see a backtrace from abort(3). I suppose it optimizes away the instructions to save the return address, because abort() is marked with __attribute__(noreturn). But that means there is very little point in actually doing that optimization since __attribute__(noreturn) implies that the function will only be called once! I suppose there are some space savings but are they really significant?
Re: Problem reading corefiles on ARM
On Wed, Aug 06, 2008 at 05:42:48PM +0200, Mark Kettenis wrote: > GCC should really not do this. People are almost guaranteed to want > to be able to see a backtrace from abort(3). Yes, it's come up for discussion several times... I don't like the current behavior either. The current behavior was added many years ago for an unspecified application :-( /* Decide if the current function is volatile. Such functions never return, and many memory cycles can be saved by not storing register values that will never be needed again. This optimization was added to speed up context switching in a kernel application. */ IMO that shouldn't be written in C, then... -- Daniel Jacobowitz CodeSourcery
Re: Problem reading corefiles on ARM
> "Mark" == Mark Kettenis <[EMAIL PROTECTED]> writes: >> Date: Wed, 6 Aug 2008 11:27:36 -0400 From: Daniel Jacobowitz >> <[EMAIL PROTECTED]> >> >> On Wed, Aug 06, 2008 at 07:19:26PM +0400, Sergei Poselenov wrote: >> > (gdb) bt > #0 0x4004ec0c in raise () from /lib/libc.so.6 > #1 >> 0x40050234 in abort () from /lib/libc.so.6 > Backtrace stopped: >> frame did not save the PC >> >> Your implementation of abort does not save a return address, so >> GDB can't display it. I believe tehis is a known limitation of >> the ARM GCC port. Mark> GCC should really not do this. People are almost guaranteed to Mark> want to be able to see a backtrace from abort(3). Absolutely. Mark> I suppose it optimizes away the instructions to save the return Mark> address, because abort() is marked with Mark> __attribute__(noreturn). But that means there is very little Mark> point in actually doing that optimization since Mark> __attribute__(noreturn) implies that the function will only be Mark> called once! I suppose there are some space savings but are Mark> they really significant? I think the space savings in "noreturn" come from not having to save caller-saved registers in the calling function. That savings can add up if the noreturn function is called from many places. Clearly the return address needs to be saved in the case of functions like "abort". Come to think of it, probably all the usual registers should be saved, so you can examine variables in the function that called abort and not get nonsense. It sounds to me like the "noreturn" attribute should be removed from "abort". paul
Update libtool? (was: Re: libstdc++, gdb and darwin)
Jack Howarth wrote: > Peter, > Thanks. If gcc's libtool is missing this dsymutil workaround, it would > be nice if this could be fixed for both gcc trunk and 4.3.2. > Jack I went and looked for the patches that added dsymutil to libtool, looks like I took the opportunity to rewrite all the darwin bits at the same time, then had a couple of follow-up patches to fix bugs that I introduced. It is not a small patch. I wonder what the chances are of moving mainline gcc to a newer libtool version? Introducing the darwin bits piecemeal would not be particularly fun. Peter -- Peter O'Gorman http://pogma.com
Re: Update libtool? (was: Re: libstdc++, gdb and darwin)
Peter, You are going to fix this on gcc trunk in any case, right? Jack On Wed, Aug 06, 2008 at 11:17:03AM -0500, Peter O'Gorman wrote: > Jack Howarth wrote: > > Peter, > > Thanks. If gcc's libtool is missing this dsymutil workaround, it would > > be nice if this could be fixed for both gcc trunk and 4.3.2. > > Jack > > I went and looked for the patches that added dsymutil to libtool, looks > like I took the opportunity to rewrite all the darwin bits at the same > time, then had a couple of follow-up patches to fix bugs that I > introduced. It is not a small patch. > > I wonder what the chances are of moving mainline gcc to a newer libtool > version? Introducing the darwin bits piecemeal would not be particularly > fun. > > Peter > -- > Peter O'Gorman > http://pogma.com
Re: Update libtool?
Jack Howarth wrote: > Peter, > You are going to fix this on gcc trunk in any case, right? If there is a consensus that now is not the time to update libtool in trunk, then I will have to :) > Jack > > On Wed, Aug 06, 2008 at 11:17:03AM -0500, Peter O'Gorman wrote: >> Jack Howarth wrote: >>> Peter, >>> Thanks. If gcc's libtool is missing this dsymutil workaround, it would >>> be nice if this could be fixed for both gcc trunk and 4.3.2. >>> Jack >> I went and looked for the patches that added dsymutil to libtool, looks >> like I took the opportunity to rewrite all the darwin bits at the same >> time, then had a couple of follow-up patches to fix bugs that I >> introduced. It is not a small patch. >> >> I wonder what the chances are of moving mainline gcc to a newer libtool >> version? Introducing the darwin bits piecemeal would not be particularly >> fun. >> >> Peter >> -- >> Peter O'Gorman >> http://pogma.com -- Peter O'Gorman http://pogma.com
GCC Tests For ARM/Neon
Hi, I have just posted the first gcc test results for arm-rtems to gcc-testresults. C/C++: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00608.html Ada: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00601.html There were a lot (2116) of "unexpected failures" for C, but most (1997 by grep) appear to be because the ep7312 is not a Neon CPU and the tests did not even compiler. As with other RTEMS test configurations, we are passing an explicit CPU model CFLAGS (-mcpu=arm7tdmi). Any suggestions on how this entire set of tests can detect they don't apply? -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: GCC Tests For ARM/Neon
On Wed, 6 Aug 2008, Joel Sherrill wrote: > Hi, > > I have just posted the first gcc test results > for arm-rtems to gcc-testresults. > C/C++: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00608.html > Ada: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00601.html > > There were a lot (2116) of "unexpected failures" > for C, but most (1997 by grep) appear to be because > the ep7312 is not a Neon CPU and the tests did not > even compiler. > > As with other RTEMS test configurations, we are > passing an explicit CPU model CFLAGS (-mcpu=arm7tdmi). > > Any suggestions on how this entire set of > tests can detect they don't apply? They all use the arm_neon_ok effective target. Possibly that should check that NEON is enabled when passing -mfpu=neon -mfloat-abi=softfp (i.e. that __ARM_NEON__ is defined) rather than simply that the compiler does not give an error, if the problem is that your multilib options (passed after the options specific to the tests) disable NEON. Or if the combination is simply incompatible, possibly the compiler should be giving an error for it. -- Joseph S. Myers [EMAIL PROTECTED]
Loop Detection in IPA
Apologies to those who follow GCC-help; I posted something very similar there yesterday without really thinking. I believe this better belongs here however. I'm looking to get loop information in an IPA pass; However, as near as I can tell by the time the ipa-passes are called, the loop information is gone (ie x_current_loops is null). Is it possible to regenerate that information? As a hack, I believe I could manually set cfun to the function i'm working on at the time and call flow_loops_find(). However, I doubt this would be the proper way to do it. Is there a more reccomended way? Thanks in advance, and apologies again for the crosspost. -- Matt G.
New test is invalid for AVR
Hi All, The new test gcc.c-torture/compile/20080806-1.c, added by Andreas Krebbel on 2008-08-06, causes 8 new test failures for the AVR target. This test is invalid for the AVR because the local array is too large for the AVR (64+ K). IIRC, for testing purposes the AVR target only allows a 2K stack. Could someone please mark this test as unsupported for avr-*-*? I don't have copyright assignment yet (but we're currently working with the FSF on it). Thanks for your help. Eric Weddington Atmel
Re: GCC Tests For ARM/Neon
Joseph S. Myers wrote:
On Wed, 6 Aug 2008, Joel Sherrill wrote:
Hi,
I have just posted the first gcc test results
for arm-rtems to gcc-testresults.
C/C++: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00608.html
Ada: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00601.html
There were a lot (2116) of "unexpected failures"
for C, but most (1997 by grep) appear to be because
the ep7312 is not a Neon CPU and the tests did not
even compiler.
As with other RTEMS test configurations, we are
passing an explicit CPU model CFLAGS (-mcpu=arm7tdmi).
Any suggestions on how this entire set of
tests can detect they don't apply?
They all use the arm_neon_ok effective target. Possibly that should check
that NEON is enabled when passing -mfpu=neon -mfloat-abi=softfp (i.e. that
__ARM_NEON__ is defined) rather than simply that the compiler does not
give an error, if the problem is that your multilib options (passed after
the options specific to the tests) disable NEON. Or if the combination is
simply incompatible, possibly the compiler should be giving an error for
it.
I see the code for arm_neon_ok. If I can make that test fail,
we are in business. I tried the cpp part of the following code
and it doesn't trip for:
arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
test_neon.c
But when I added the "neon_code" function with the
assembly code gas didn't like in one of the tests, I
get a compilation error.
Do you have any better suggestion on how to make
arm_neon_ok fail? Or is this OK to add to the
macro?
==
#if !defined(__ARM_NEON__)
#error "Neon not supported"
#endif
void neon_code(void)
{
asm volatile ("vldr d18,[fp,#-32]");
}
==
--
Joseph S. Myers
[EMAIL PROTECTED]
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
RE: New test is invalid for AVR
Weddington, Eric wrote on 06 August 2008 17:49: > Hi All, > > The new test gcc.c-torture/compile/20080806-1.c, added by Andreas Krebbel > on 2008-08-06, causes 8 new test failures for the AVR target. This test > is invalid for the AVR because the local array is too large for the AVR > (64+ K). IIRC, for testing purposes the AVR target only allows a 2K > stack. > > Could someone please mark this test as unsupported for avr-*-*? I don't > have copyright assignment yet (but we're currently working with the FSF > on it). Actually shouldn't it be dealt with by the small-stack handling in the testsuite infrastructure? My board.exp (for a similarly small embedded target) has these lines: # We only have a small stack available to us set_board_info gcc,stack_size 2048 ... which somehow get translated into a -DSTACK_SIZE=xxx that can be tested and/or used numerically in the regression test sources. cheers, DaveK -- Can't think of a witty .sigline today
Re: Problem reading corefiles on ARM
On Wed, Aug 06, 2008 at 11:54:42AM -0400, Paul Koning wrote:
> I think the space savings in "noreturn" come from not having to save
> caller-saved registers in the calling function. That savings can add
> up if the noreturn function is called from many places.
>
> Clearly the return address needs to be saved in the case of functions
> like "abort". Come to think of it, probably all the usual registers
> should be saved, so you can examine variables in the function that
> called abort and not get nonsense.
>
> It sounds to me like the "noreturn" attribute should be removed from
> "abort".
I don't think that this is the right way to go.
There are several effects from "noreturn". We would want some of these
effects for "abort", but not others, to get debuggable code without
degrading compile-time warnings.
For the function
#include
int func(int arg) {
switch (arg) {
case 0: return 23;
case 1: return 42;
default: abort();
}
}
getting rid of the "noreturn" attribute on abort() would make -Wall
give the warning
foo.c: In function `func':
foo.c:9: warning: control reaches end of non-void function
So, to produce debuggable code, instead of getting rid of the attribute,
we should instead keep the attribute, as well as enough information to
debug.
Some users will want the maximum optimization even if it impedes
debugging. We already have -fomit-frame-pointer, which leaves out
information on stack frames. Perhaps that flag could also enable
(or in its absence, disable) the omission of information about
calls to noreturn functions. An alternative would be a separate flag.
Re: GCC Tests For ARM/Neon
On Wed, 6 Aug 2008, Joel Sherrill wrote: > I see the code for arm_neon_ok. If I can make that test fail, > we are in business. I tried the cpp part of the following code > and it doesn't trip for: > > arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c test_neon.c > > But when I added the "neon_code" function with the > assembly code gas didn't like in one of the tests, I > get a compilation error. > > Do you have any better suggestion on how to make > arm_neon_ok fail? Or is this OK to add to the > macro? You should not need to add the assembly code. If NEON is not in fact effectively enabled then the preprocessor macro should not be defined. -- Joseph S. Myers [EMAIL PROTECTED]
RE: New test is invalid for AVR
> -Original Message- > From: Dave Korn [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 06, 2008 11:04 AM > To: Weddington, Eric; gcc@gcc.gnu.org > Cc: 'Andy Hutchinson'; 'Anatoly Sokolov'; 'Andreas Krebbel'; > [EMAIL PROTECTED] > Subject: RE: New test is invalid for AVR > > Weddington, Eric wrote on 06 August 2008 17:49: > > > Could someone please mark this test as unsupported for > avr-*-*? I don't > > have copyright assignment yet (but we're currently working > with the FSF > > on it). > > Actually shouldn't it be dealt with by the small-stack > handling in the > testsuite infrastructure? My board.exp (for a similarly > small embedded > target) has these lines: > > # We only have a small stack available to us > set_board_info gcc,stack_size 2048 > > ... which somehow get translated into a -DSTACK_SIZE=xxx that > can be tested > and/or used numerically in the regression test sources. Bear with me, here, as I'm new to running the test suite and how it all works... I do have that line that you have in my atmega128-sim.exp: set_board_info gcc,stack_size 2048 I see in the test results that -DSTACK_SIZE=2048 is correctly getting passed in when this test is being compiled. Beyond that, I don't know what is supposed to be done to mark this test as unsupported for the AVR. Thanks, Eric Weddington
Re: Problem reading corefiles on ARM
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: Joe> On Wed, Aug 06, 2008 at 11:54:42AM -0400, Paul Koning wrote: >> I think the space savings in "noreturn" come from not having to >> save caller-saved registers in the calling function. That savings >> can add up if the noreturn function is called from many places. >> >> Clearly the return address needs to be saved in the case of >> functions like "abort". Come to think of it, probably all the >> usual registers should be saved, so you can examine variables in >> the function that called abort and not get nonsense. >> >> It sounds to me like the "noreturn" attribute should be removed >> from "abort". Joe> I don't think that this is the right way to go. Joe> There are several effects from "noreturn". We would want some Joe> of these effects for "abort", but not others, to get debuggable Joe> code without degrading compile-time warnings. Good point. So the issue is that two unrelated features are currently combined in a single attribute: 1. This function doesn't return, do the right thing with warnings in the caller of this function. 2. Don't bother saving registers when calling this function because it won't return so the registers aren't needed afterwards. The issue is that #2 doesn't apply to "abort" because the registers ARE needed afterwards -- at debug time. One possibility is to have "noreturn" mean #1 only, and invent a new flag for #2. The alternative is to have "noreturn" mean both (as today) and invent a new flag to cancel #2. I'd suggest the former because that's the more likely case. It's hard to think of examples where #2 is needed (or at least, where it is important). paul
Re: Problem reading corefiles on ARM
I wrote: > Joe> There are several effects from "noreturn". We would want some > Joe> of these effects for "abort", but not others, to get debuggable > Joe> code without degrading compile-time warnings. On Wed, Aug 06, 2008 at 01:37:51PM -0400, Paul Koning wrote: > So the issue is that two unrelated features are currently combined in > a single attribute: > > 1. This function doesn't return, do the right thing with warnings in >the caller of this function. > > 2. Don't bother saving registers when calling this function because it >won't return so the registers aren't needed afterwards. > > The issue is that #2 doesn't apply to "abort" because the registers > ARE needed afterwards -- at debug time. But not necessarily all of them (depending on platform). That is, the caller-saved registers don't have to be saved because the function isn't returning, but there has to be enough of a stack frame so that a debugger can set a breakpoint on the abort and determine who the caller was. > One possibility is to have "noreturn" mean #1 only, and invent a new > flag for #2. The alternative is to have "noreturn" mean both (as > today) and invent a new flag to cancel #2. > > I'd suggest the former because that's the more likely case. It's hard > to think of examples where #2 is needed (or at least, where it is > important). Evidently there was a motivating application where #2 was an important optimization. Still, I think you're right that it would be better to do it only if the optimization is asked for (via a new flag).
Re: Problem reading corefiles on ARM
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: Joe> I wrote: There are several effects from "noreturn". We would Joe> want some of these effects for "abort", but not others, to get Joe> debuggable code without degrading compile-time warnings. Joe> On Wed, Aug 06, 2008 at 01:37:51PM -0400, Paul Koning wrote: >> So the issue is that two unrelated features are currently combined >> in a single attribute: >> >> 1. This function doesn't return, do the right thing with warnings >> in the caller of this function. >> >> 2. Don't bother saving registers when calling this function >> because it won't return so the registers aren't needed afterwards. >> >> The issue is that #2 doesn't apply to "abort" because the >> registers ARE needed afterwards -- at debug time. Joe> But not necessarily all of them (depending on platform). That Joe> is, the caller-saved registers don't have to be saved because Joe> the function isn't returning, but there has to be enough of a Joe> stack frame so that a debugger can set a breakpoint on the abort Joe> and determine who the caller was. That's sufficient for live debugging but not for corefiles. In that case you do want caller-saved registers, because they may contain local variable values that don't live in memory at the time of the abort call. paul
RE: New test is invalid for AVR
[ Oh, hi Andreas, I just saw you're Cc'd into this thread! I guess that post I sent to the -patches list was a bit superfluous then, sorry about that! ] Weddington, Eric wrote on 06 August 2008 18:14: > I do have that line that you have in my atmega128-sim.exp: > set_board_info gcc,stack_size 2048 > > I see in the test results that -DSTACK_SIZE=2048 is correctly getting > passed in when this test is being compiled. Righto. It's just that the testcase doesn't pay any regard to the STACK_SIZE macro; it's a common oversight in testcases, not a lot of people know it's even there and those who do don't always remember! > Beyond that, I don't know what is supposed to be done to mark this test > as unsupported for the AVR. The best solution is to make the test respect STACK_SIZE, and then it'll automatically work where it can work and won't work where it can't. See http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00412.html. You don't want to use the target-specific markings to disable it on AVR, because it's not really beyond conceivable that someday there will be an AVR with lots of memory somehow, and then you'd want this test to be run (and to pass!) cheers, DaveK -- Can't think of a witty .sigline today
Re: Update libtool?
* Peter O'Gorman wrote on Wed, Aug 06, 2008 at 06:26:15PM CEST: > Jack Howarth wrote: > > On Wed, Aug 06, 2008 at 11:17:03AM -0500, Peter O'Gorman wrote: > >> > >> I wonder what the chances are of moving mainline gcc to a newer libtool > >> version? Introducing the darwin bits piecemeal would not be particularly > >> fun. > > > > You are going to fix this on gcc trunk in any case, right? > > If there is a consensus that now is not the time to update libtool in > trunk, then I will have to :) First off, I am not in a position to decide anything here, so the following is just my two cents: I would be a bit concerned to update libtool in branch-4_3. Is this issue a regression? That said, updating in trunk is a different matter. There, the question IMHO is mostly which libtool version to update to. The git version may still have a regression or two, but 2.2.4 doesn't have the -fPIC on HP/IA patch from Steve (which would be trivial to backport of course). Alternatively GCC can wait for 2.2.6 (hopefully in the "couple of weeks at most" time frame). I haven't tried GCC trunk with libtool 2.2.4 yet, but I guess that should be reasonably smooth. (Of course I'd be willing to try.) AFAICS there are no GCC-specific changes in these files: libtool.m4 ltmain.sh lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4 (there has been a patch to libtool.m4 but it was subsequently backed out again.) Cheers, Ralf
Re: Update libtool?
Hi Ralf, Ralf Wildenhues wrote: > * Peter O'Gorman wrote on Wed, Aug 06, 2008 at 06:26:15PM CEST: >> Jack Howarth wrote: >>> On Wed, Aug 06, 2008 at 11:17:03AM -0500, Peter O'Gorman wrote: I wonder what the chances are of moving mainline gcc to a newer libtool version? Introducing the darwin bits piecemeal would not be particularly fun. >>> You are going to fix this on gcc trunk in any case, right? >> If there is a consensus that now is not the time to update libtool in >> trunk, then I will have to :) > > First off, I am not in a position to decide anything here, so the > following is just my two cents: > > I would be a bit concerned to update libtool in branch-4_3. Is this > issue a regression? I have no intention of asking that libtool be updated in the 4.3 branch. I do not consider it a regression, it has always been broken on Mac OS X when using dwarf2. > I haven't tried GCC trunk with libtool 2.2.4 yet, but I guess that > should be reasonably smooth. (Of course I'd be willing to try.) I am also willing to try. > > AFAICS there are no GCC-specific changes in these files: > libtool.m4 ltmain.sh lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4 > (there has been a patch to libtool.m4 but it was subsequently backed out > again.) Good to know. Thanks. Peter -- Peter O'Gorman http://pogma.com
Re: GCC Tests For ARM/Neon
Joseph S. Myers wrote: On Wed, 6 Aug 2008, Joel Sherrill wrote: I see the code for arm_neon_ok. If I can make that test fail, we are in business. I tried the cpp part of the following code and it doesn't trip for: arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c test_neon.c But when I added the "neon_code" function with the assembly code gas didn't like in one of the tests, I get a compilation error. Do you have any better suggestion on how to make arm_neon_ok fail? Or is this OK to add to the macro? You should not need to add the assembly code. If NEON is not in fact effectively enabled then the preprocessor macro should not be defined. I think GAS is doing the right thing and gcc is sending confusing information. Try the test code I posted with an arm compiler. $ arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c test_neon.c /tmp/ccBzigjD.s: Assembler messages: /tmp/ccBzigjD.s:13: Error: selected processor does not support `vldr d18,[fp,#-32]' So with that combination of options gcc defines __ARM_NEON__. And gas ends up knowing the instructions are invalid. FWIW with my addition to the arm_neon_ok, it went down to 78 unexpected failures. http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00623.html -- Joseph S. Myers [EMAIL PROTECTED] -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: GCC Tests For ARM/Neon
On Wed, 6 Aug 2008, Joel Sherrill wrote: > $ arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c > test_neon.c /tmp/ccBzigjD.s: Assembler messages: > /tmp/ccBzigjD.s:13: Error: selected processor does not support `vldr > d18,[fp,#-32]' > > > So with that combination of options gcc defines __ARM_NEON__. > And gas ends up knowing the instructions are invalid. The compiler generates .cpu arm7tdmi .fpu neon for this example. I do not think the assembler should silently accept this and then reject the instructions. I'd think it should either give an error for ".fpu neon" with incompatible CPUs, or accept the instructions. If it gives an error, the compiler should not pass the ".fpu neon", and not define __ARM_NEON__, and possibly give an error itself. -- Joseph S. Myers [EMAIL PROTECTED]
Ada Hardware Interrupt Patch
Hi, Attached is the latest revision of the Ada Hardware Interrupt patch. It has been tracked as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576 Interrupt support tested on sparc-rtems. ACATS reported on sparc, mips, i386, powerpc, and arm. 2008-08-06 Joel Sherrill <[EMAIL PROTECTED]> * gcc-interface/Makefile.in: Switch RTEMS and VxWorks to s-interr-hwint.adb. * s-interr-hwint.adb: New file with portable implementation. This is a mechanical change of s-interr-vxworks.adb to use the new OS provided adapter. * s-interr-vxworks.adb: Removed. * s-osinte-rtems.ads, s-osinte-vxworks.adb, s-osinte-vxworks.ads: Add shared hardware interrupt adapter layer. RTEMS binds to OS provided adapter routines so there are no modifications to s-osinte-rtems.adb. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 Index: gcc/ada/s-osinte-rtems.ads === --- gcc/ada/s-osinte-rtems.ads (revision 138553) +++ gcc/ada/s-osinte-rtems.ads (working copy) @@ -88,7 +88,13 @@ -- Signals -- - - Max_Interrupt : constant := 31; + Num_HW_Interrupts : constant := 256; + + Max_HW_Interrupt : constant := Num_HW_Interrupts - 1; + type HW_Interrupt is new int range 0 .. Max_HW_Interrupt; + + Max_Interrupt : constant := Max_HW_Interrupt; + type Signal is new int range 0 .. Max_Interrupt; SIGXCPU : constant := 0; -- XCPU @@ -501,6 +507,79 @@ destructor : destructor_pointer) return int; pragma Import (C, pthread_key_create, "pthread_key_create"); + + -- Binary Semaphore Wrapper to Support Interrupt Tasks -- + + + type Binary_Semaphore_Id is new rtems_id; + + function Binary_Semaphore_Create return Binary_Semaphore_Id; + pragma Import ( + C, + Binary_Semaphore_Create, + "__gnat_binary_semaphore_create"); + + function Binary_Semaphore_Delete (ID : Binary_Semaphore_Id) return int; + pragma Import ( + C, + Binary_Semaphore_Delete, + "__gnat_binary_semaphore_delete"); + + function Binary_Semaphore_Obtain (ID : Binary_Semaphore_Id) return int; + pragma Import ( + C, + Binary_Semaphore_Obtain, + "__gnat_binary_semaphore_obtain"); + + function Binary_Semaphore_Release (ID : Binary_Semaphore_Id) return int; + pragma Import ( + C, + Binary_Semaphore_Release, + "__gnat_binary_semaphore_release"); + + function Binary_Semaphore_Flush (ID : Binary_Semaphore_Id) return int; + pragma Import ( + C, + Binary_Semaphore_Flush, + "__gnat_binary_semaphore_flush"); + + + -- Hardware Interrupt Wrappers to Support Interrupt Tasks -- + + + type Interrupt_Handler is access procedure (parameter : System.Address); + pragma Convention (C, Interrupt_Handler); + type Interrupt_Vector is new System.Address; + + function Interrupt_Connect + (vector: Interrupt_Vector; + handler : Interrupt_Handler; + parameter : System.Address := System.Null_Address) return int; + pragma Import (C, Interrupt_Connect, "__gnat_interrupt_connect"); + -- Use this to set up an user handler. The routine installs a + -- a user handler which is invoked after RTEMS has saved enough + -- context for a high-level language routine to be safely invoked. + + function Interrupt_Vector_Get + (Vector : Interrupt_Vector) return Interrupt_Handler; + pragma Import (C, Interrupt_Vector_Get, "__gnat_interrupt_get"); + -- Use this to get the existing handler for later restoral. + + procedure Interrupt_Vector_Set + (Vector : Interrupt_Vector; + Handler : Interrupt_Handler); + pragma Import (C, Interrupt_Vector_Set, "__gnat_interrupt_set"); + -- Use this to restore a handler obtained using Interrupt_Vector_Get. + + function Interrupt_Number_To_Vector (intNum : int) return Interrupt_Vector; + -- Convert a logical interrupt number to the hardware interrupt vector + -- number used to connect the interrupt. + pragma Import ( + C, + Interrupt_Number_To_Vector, + "__gnat_interrupt_number_to_vector" + ); + private type sigset_t is new int; @@ -533,7 +612,7 @@ schedpolicy : int; schedparam : struct_sched_param; cputime_clocked_allowed : int; - deatchstate : int; + detatchstate: int; end record; pragma Convention (C, pthread_attr_t); Index: gcc/ada/s-osinte-vxworks.adb === --- gcc/ada/s-osinte-vxworks.adb (revision 138553) +++ gcc/ada/s-osi
Re: Problem reading corefiles on ARM
Paul Koning <[EMAIL PROTECTED]> writes: > That's sufficient for live debugging but not for corefiles. In that > case you do want caller-saved registers, because they may contain > local variable values that don't live in memory at the time of the > abort call. In an optimized build you can't expect any local variable to survive, since it may just be dead before the call, or its value may be unavailable for any other reason. The use of the noreturn attribute only adds little to this. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Problem reading corefiles on ARM
Paul Koning <[EMAIL PROTECTED]> writes:
> > That's sufficient for live debugging but not for corefiles. In that
> > case you do want caller-saved registers, because they may contain
> > local variable values that don't live in memory at the time of the
> > abort call.
On Wed, Aug 06, 2008 at 11:38:14PM +0200, Andreas Schwab wrote:
> In an optimized build you can't expect any local variable to survive,
> since it may just be dead before the call, or its value may be
> unavailable for any other reason. The use of the noreturn attribute
> only adds little to this.
Agreed. I think that the objective should be that if there is an abort
call, then from either a core dump or when gdb'ing a live process it
should be possible to determine the call site of the abort() call, even
with -O2/-Os. But beyond that, the optimizer should be free, just as
in other cases, to discard values in registers that will never be used
again.
After all, if we have
int func1(int);
void func2(int);
void ordinary_function(void);
void func(int arg) {
int v1 = func1(arg);
func2(v1);
ordinary_function();
}
and there's a segfault in ordinary_function, in general v1 isn't
going to be kept around for inspection in the core dump. So why
should we impose a stricter requirement if ordinary_function is
replaced by abort() ? It seems Paul thinks we should be required
to save v1 if there's an abort call, unless I'm misunderstanding.
gcc-4.2-20080806 is now available
Snapshot gcc-4.2-20080806 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080806/ 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 138828 You'll find: gcc-4.2-20080806.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080806.tar.bz2 C front end and core compiler gcc-ada-4.2-20080806.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080806.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080806.tar.bz2 C++ front end and runtime gcc-java-4.2-20080806.tar.bz2 Java front end and runtime gcc-objc-4.2-20080806.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080806.tar.bz2The GCC testsuite Diffs from 4.2-20080730 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: Problem reading corefiles on ARM
> From: mark@ > To: drow@; gcc@ > CC: sposelenov@; gdb@ > I suppose it optimizes away the instructions to save the return > address, because abort() is marked with __attribute__(noreturn). But Ouch. Other compilers put a breakpoint after a call to any noreturn function. Really, the compiler, not the debugger. I had an incorrect annotation once. :) - Jay
Re: Update libtool?
That said, updating in trunk is a different matter. There, the question IMHO is mostly which libtool version to update to. The git version may still have a regression or two, but 2.2.4 doesn't have the -fPIC on HP/IA patch from Steve (which would be trivial to backport of course). Alternatively GCC can wait for 2.2.6 (hopefully in the "couple of weeks at most" time frame). Updating to 2.2.6 would be okay for me. Paolo
