Re: Generating ancilliary sections with gas

2011-02-02 Thread Alan Modra 
Have you seen http://sourceware.org/ml/binutils/2010-08/msg00121.html ?

-- 
Alan Modra
Australia Development Lab, IBM

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Generating ancilliary sections with gas

2011-02-02 Thread Dave Martin 
On Tue, Feb 1, 2011 at 11:48 PM, Alan Modra  wrote:
> Have you seen http://sourceware.org/ml/binutils/2010-08/msg00121.html ?

That's interesting--- I hadn't fully understood what this did.

I'm not sure it solves my problem though: I need to generate ancillary
sectiions relating for normal sections, and I need the relationship to
be visible in the name so that a linker script can remove related
sections in a sane way.

I think my proposal allows for a solution to the general problem of
allowing assembler directives to do things based on the current
assembler state, where "?" solves only a specific instance of that
problem, just allowing .section and related directives to do something
quite specific based on a specific property of the assembler state
(the current section group name).

If I'm wrong and you can see how to solve my problem, I'd definitely
be interested though.

Cheers
---Dave

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: IT block semantic question

2011-02-02 Thread Dave Martin 
On Tue, Feb 1, 2011 at 12:33 PM, David Gilbert  wrote:
> Hi,
>  What do people understand to be the expected semantics of IT blocks
> in the cases below, of which there has been some confusion
> in relation to a recent Qt issue.
>
>  The code in question had a sequence something like:
>
>
>  comparison
>  IT... EQ
>  blahEQ
>  TEQ
>  BEQ
>
> The important bits here are that we have an IT EQ block and two special cases:
>
>  1) There is a TEQ in the IT block - are all comparisons in the block
> allowed and do their effects immediately take
> effect?  As far as I can tell this is allowed and any flag changes are
> used straight away;

Yes; yes; and: you're right.  This was a specific intention, since
there was always a common idiom on ARM of sequences like this:

CMP r0, #1
CMPEQ r1, #2
CMPEQ r2, #3
BEQ ...

with the effect of "if(r0==1 && r1==2 && r2==3) ..."

>
>  2) There is a BEQ at the end of the IT block, as far as I can tell,
> as long as the destination of the BEQ is close it shouldn't
> make any difference if the BEQ is included in the IT block or not.

Again, I believe you're right.  The assembler will generate different
code, because the explicit conditional branch encodings are not
allowed in IT blocks.  But the assembler takes care of this for you:

 :
   0:   d001beq.n   6 

versus

   2:   bf08it  eq
   4:   e7ffbeq.n   6 

0006 :

Both snippets are equivalent, though as you say, with IT you can
insert more code between the branch and its destination before the
assembler will barf with a fixup overflow, because the unconditional
branch encoding (e000..e7fff) has more bits to express the branch
offset.

Cheers
---Dave

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: IT block semantic question

2011-02-02 Thread David Gilbert 
On 2 February 2011 10:47, Dave Martin  wrote:
> On Tue, Feb 1, 2011 at 12:33 PM, David Gilbert  
> wrote:
>> Hi,
>>  What do people understand to be the expected semantics of IT blocks
>> in the cases below, of which there has been some confusion
>> in relation to a recent Qt issue.
>>
>>  The code in question had a sequence something like:
>>
>>
>>  comparison
>>  IT... EQ
>>  blahEQ
>>  TEQ
>>  BEQ
>>
>> The important bits here are that we have an IT EQ block and two special 
>> cases:
>>
>>  1) There is a TEQ in the IT block - are all comparisons in the block
>> allowed and do their effects immediately take
>> effect?  As far as I can tell this is allowed and any flag changes are
>> used straight away;
>
> Yes; yes; and: you're right.  This was a specific intention, since
> there was always a common idiom on ARM of sequences like this:
>
> CMP r0, #1
> CMPEQ r1, #2
> CMPEQ r2, #3
> BEQ ...
>
> with the effect of "if(r0==1 && r1==2 && r2==3) ..."
>
>>
>>  2) There is a BEQ at the end of the IT block, as far as I can tell,
>> as long as the destination of the BEQ is close it shouldn't
>> make any difference if the BEQ is included in the IT block or not.
>
> Again, I believe you're right.  The assembler will generate different
> code, because the explicit conditional branch encodings are not
> allowed in IT blocks.  But the assembler takes care of this for you:
>
>  :
>   0:   d001            beq.n   6 
>
> versus
>
>   2:   bf08            it      eq
>   4:   e7ff            beq.n   6 
>
> 0006 :
>
> Both snippets are equivalent, though as you say, with IT you can
> insert more code between the branch and its destination before the
> assembler will barf with a fixup overflow, because the unconditional
> branch encoding (e000..e7fff) has more bits to express the branch
> offset.

Thanks for the confirmation Dave.

Dave

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: IT block semantic question

2011-02-02 Thread Dave Martin 
On Wed, Feb 2, 2011 at 11:04 AM, David Gilbert  wrote:
> On 2 February 2011 10:47, Dave Martin  wrote:
>> On Tue, Feb 1, 2011 at 12:33 PM, David Gilbert  
>> wrote:
>>> Hi,
>>>  What do people understand to be the expected semantics of IT blocks
>>> in the cases below, of which there has been some confusion
>>> in relation to a recent Qt issue.
>>>
>>>  The code in question had a sequence something like:
>>>
>>>
>>>  comparison
>>>  IT... EQ
>>>  blahEQ
>>>  TEQ
>>>  BEQ
>>>
>>> The important bits here are that we have an IT EQ block and two special 
>>> cases:
>>>
>>>  1) There is a TEQ in the IT block - are all comparisons in the block
>>> allowed and do their effects immediately take
>>> effect?  As far as I can tell this is allowed and any flag changes are
>>> used straight away;
>>
>> Yes; yes; and: you're right.  This was a specific intention, since
>> there was always a common idiom on ARM of sequences like this:
>>
>> CMP r0, #1
>> CMPEQ r1, #2
>> CMPEQ r2, #3
>> BEQ ...
>>
>> with the effect of "if(r0==1 && r1==2 && r2==3) ..."
>>
>>>
>>>  2) There is a BEQ at the end of the IT block, as far as I can tell,
>>> as long as the destination of the BEQ is close it shouldn't
>>> make any difference if the BEQ is included in the IT block or not.
>>
>> Again, I believe you're right.  The assembler will generate different
>> code, because the explicit conditional branch encodings are not
>> allowed in IT blocks.  But the assembler takes care of this for you:
>>
>>  :
>>   0:   d001            beq.n   6 
>>
>> versus
>>
>>   2:   bf08            it      eq
>>   4:   e7ff            beq.n   6 
>>
>> 0006 :
>>
>> Both snippets are equivalent, though as you say, with IT you can
>> insert more code between the branch and its destination before the
>> assembler will barf with a fixup overflow, because the unconditional
>> branch encoding (e000..e7fff) has more bits to express the branch
>> offset.
>
> Thanks for the confirmation Dave.

The key things I'm aware of that you need to what out for with IT are:

 * A few instructions (such as IT itself) are not allowed inside IT blocks.
 * branching into the middle of an IT block
 * only the last instruction in an IT block is allowed to be a branch
(B{L}, B{L}X, LDR pc, LDM/POP ... {pc} etc.)

These result in undefined behaviour.

The compiler should never make these mistakes, but it could happen in
hand-written assembler.

The assembler will often warn you about such cases, but be vigilant---
there are some it won't pick up at present.

Cheers
---Dave

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

do we consider extravagant memory usage a gcc bug?

2011-02-02 Thread Peter Maydell 
Trying to build qemu on a beagle board:

  CCsparc64-linux-user/translate.o

cc1: out of memory allocating 26975704 bytes after a total of 70742016 bytes

# ls -lh target-sparc/translate.c
-rw-r--r-- 1 root root 191K Jan 31 12:05 target-sparc/translate.c

ie gcc wants (at least) 100M of RAM trying to compile a 190K sourcefile.
(and probably more overall since the board has 500MB RAM total and
it hit the out-of-memory condition).

This seems a bit excessive to me, but do we consider it enough of
a bug to be worth looking into?

(I believe this source file has caused compile failures on the buildds
too, which have rather more RAM/swap than my beagle.)

-- PMM

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: do we consider extravagant memory usage a gcc bug?

2011-02-02 Thread Peter Maydell 
On 2 February 2011 11:54, Peter Maydell  wrote:
> ie gcc wants (at least) 100M of RAM trying to compile a 190K sourcefile.
> (and probably more overall since the board has 500MB RAM total and
> it hit the out-of-memory condition).

On a rerun which hit the kernel OOM-killer the kernel said:
Killed process 5362 (cc1) vsz:480472kB, anon-rss:469676kB, file-rss:88kB

so gcc's claim that it only wanted 100MB is underreading rather.

-- PMM

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: do we consider extravagant memory usage a gcc bug?

2011-02-02 Thread David Gilbert 
On 2 February 2011 12:28, Peter Maydell  wrote:
> On 2 February 2011 11:54, Peter Maydell  wrote:
>> ie gcc wants (at least) 100M of RAM trying to compile a 190K sourcefile.
>> (and probably more overall since the board has 500MB RAM total and
>> it hit the out-of-memory condition).
>
> On a rerun which hit the kernel OOM-killer the kernel said:
> Killed process 5362 (cc1) vsz:480472kB, anon-rss:469676kB, file-rss:88kB
>
> so gcc's claim that it only wanted 100MB is underreading rather.

480MB does appear excessive; to be a little fair to gcc that file does
look like it's trying to
build itself as a vast inline'd set of switch statements so it will be
stressing the compiler.

Is this 480MB much more than on x86 or on older versions of the compiler?

Dave
(resend remembering to hit all)

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: do we consider extravagant memory usage a gcc bug?

2011-02-02 Thread Peter Maydell 
On 2 February 2011 13:16, David Gilbert  wrote
> 480MB does appear excessive; to be a little fair to gcc that file does
> look like it's trying to
> build itself as a vast inline'd set of switch statements so it will be
> stressing the compiler.
>
> Is this 480MB much more than on x86 or on older versions of the compiler?

A quick binary-chop using ulimit on x86-32 but the same gcc
"gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5" shows that on x86-32
you need about 284000K to compile this translation unit.

I haven't established exactly how much memory we need on ARM;
it's more than 480MB but less than 55K. (It takes way too long
to compile the file to do a sensible binary chop.)

The resulting .o file is 1.5M on x86-32 and 1.6M on ARM
(presumably partly due to debug info as we are compiling with
-g -O2).

-- PMM

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: do we consider extravagant memory usage a gcc bug?

2011-02-02 Thread Jani Monoses 

On 02/02/2011 01:54 PM, Peter Maydell wrote:

Trying to build qemu on a beagle board:

   CCsparc64-linux-user/translate.o

cc1: out of memory allocating 26975704 bytes after a total of 70742016 bytes

# ls -lh target-sparc/translate.c
-rw-r--r-- 1 root root 191K Jan 31 12:05 target-sparc/translate.c

ie gcc wants (at least) 100M of RAM trying to compile a 190K sourcefile.
(and probably more overall since the board has 500MB RAM total and
it hit the out-of-memory condition).

This seems a bit excessive to me, but do we consider it enough of
a bug to be worth looking into?

(I believe this source file has caused compile failures on the buildds
too, which have rather more RAM/swap than my beagle.)


Right, looks similar to the error from
http://launchpadlibrarian.net/62973330/buildlog_ubuntu-natty-armel.qemu-kvm_0.13.0%2Bnoroms-0ubuntu12_FAILEDTOBUILD.txt.gz

...
  CCsparc64-softmmu/translate.o
virtual memory exhausted: Cannot allocate memory
...

and those build machines have 512M RAM and many Gb of swap from what I know.

Jani


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: qemu-linaro prerelease available

2011-02-02 Thread Peter Maydell 
On 27 January 2011 18:07, Peter Maydell  wrote:
> Hi; this is a note to say that we have now produced a prerelease
> tarball of qemu-linaro. (The first formal qemu-linaro release will
> happen in sync with other toolchain group releases on 8th Feb.)

The prerelease has done its job in that it has flushed out several
minor bugs, which we have fixed in an RC2 candidate.

Again, the enthusiastic (and toolchain group people who want to
do some prerelease testing) can download the source tarball:
 https://launchpad.net/qemu-linaro/11.05/2011.02-rc2

-- Peter Maydell

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

gcc-linaro-4.5+bzr99469 build failure

2011-02-02 Thread Michael Hope 
The current revision fails to bootstrap on i686:

http://ex.seabright.co.nz/build/gcc-linaro-4.5+bzr99469/logs/i686-lucid-cbuild45-scorpius-i686r1/gcc-build.txt
libtool: compile:
/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/./gcc/xgcc
-shared-libgcc 
-B/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/./gcc
-nostdinc++ 
-L/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/i686-pc-linux-gnu/libstdc++-v3/src
-L/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/bin/
-B/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/lib/
-isystem 
/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/include
-isystem 
/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I../../../gcc-linaro-4.5/libjava -I./include
-I./gcj -I../../../gcc-linaro-4.5/libjava -Iinclude
-I../../../gcc-linaro-4.5/libjava/include
-I../../../gcc-linaro-4.5/libjava/classpath/include
-Iclasspath/include
-I../../../gcc-linaro-4.5/libjava/classpath/native/fdlibm
-I../../../gcc-linaro-4.5/libjava/../boehm-gc/include
-I../boehm-gc/include -I../../../gcc-linaro-4.5/libjava/libltdl
-I../../../gcc-linaro-4.5/libjava/libltdl
-I../../../gcc-linaro-4.5/libjava/.././libjava/../gcc
-I../../../gcc-linaro-4.5/libjava/../zlib
-I../../../gcc-linaro-4.5/libjava/../libffi/include
-I../libffi/include -fno-rtti -fnon-call-exceptions
-fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64
-ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall -D_GNU_SOURCE
-DPREFIX=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install\"
-DTOOLEXECLIBDIR=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/lib\"
-DJAVA_HOME=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install\"
-DBOOT_CLASS_PATH=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/share/java/libgcj-4.5.2.jar\"
-DJAVA_EXT_DIRS=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/share/java/ext\"
-DGCJ_ENDORSED_DIRS=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/share/java/gcj-endorsed\"
-DGCJ_VERSIONED_LIBDIR=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/lib/gcj-4.5.2-11\"
-DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\"
-DLIBGCJ_DEFAULT_DATABASE=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/lib/gcj-4.5.2-11/classmap.db\"
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.5.2-11/classmap.db\" -g
-O2 -D_GNU_SOURCE -MT exception.lo -MD -MP -MF .deps/exception.Tpo -c
../../../gcc-linaro-4.5/libjava/exception.cc -o exception.o >/dev/null
2>&1
../../../gcc-linaro-4.5/libjava/prims.cc: In function 'jboolean
_Jv_isPrimitiveOrDerived(const Utf8Const*)':
../../../gcc-linaro-4.5/libjava/prims.cc:287:5: internal compiler
error: in set_jump_prob, at stmt.c:2211
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The log is available here:
 
http://builds.linaro.org/toolchain/gcc-linaro-4.5+bzr99469/logs/i686-lucid-cbuild45-scorpius-i686r1/gcc-build.txt

-- Michael

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain