Eureka! AVR32 ld-uClibc.so segfault solved

Eureka! AVR32 ld-uClibc.so segfault solved

[Geoffrey Wossum]

Hi all,

I just tracked down the culprit for my AVR32 system always segfaulting 
whenever ld-uClibc.so ran (usually as soon as the kernel attempted to run the 
init process).

Turns out that while most of uClibc is not particularly sensitive to the 
CFLAGS, ld-uClibc.so is extremely sensitive.  The uclibc.inc file was doing 
some things that screwed up the CFLAGS being used to compile ld-uClibc.so.

Here's the diff that made it all work:
--- uclibc.inc  7 Mar 2008 21:50:53 -0000       1.3
+++ uclibc.inc  12 Mar 2008 20:35:44 -0000
@@ -70,7 +70,7 @@

 # do_stage barfs on a CC with whitepspace, therefore put the 'HOST_CC_ARCH' 
in
 # the CFLAGS (for when building the utils).
-OEMAKE_NO_CC= "'OPTIMIZATION=' 'CPU_CFLAGS=${CFLAGS}' 'STRIPTOOL=true' 'LD=${LD}'\
+OEMAKE_NO_CC = "'STRIPTOOL=true' 'LD=${LD}' \
                'LOCALE_DATA_FILENAME=${UCLIBC_LOCALE_FILE}'"
 EXTRA_OEMAKE = "${OEMAKE_NO_CC} 'CC=${CC}'"
 EXTRA_OEMAKE_task_do_populate_staging = "${OEMAKE_NO_CC}"


Now, I'm not sure what consequences this has to the overall system and other 
platforms.  I'm not exactly sure why you'd always want to wipe out the 
OPTIMIZATION and CPU_CFLAGS that the uClibc Rules.mak sets up, either.  
Comments on these points?


So I now have a working OE based AVR32 build system, using binutils 
2.17.atmel.0.0.99 20060623, gcc 4.2.1-atmel.1.0.3, and uClibc 0.9.29-atmel.1.  
This is essentially the same as Atmel's buildroot-avr32-v2.1.0.  As soon as I 
clean stuff up a little, I'll submit patches for this via bugzilla.  Minus 
this uclibc.inc diff.  I need more expert opinion on this.

Thanks to all those who helped!
---
Geoffrey

Re: Eureka! AVR32 ld-uClibc.so segfault solved

[Robert Wörle]

> So I now have a working OE based AVR32 build system, using binutils 
> 2.17.atmel.0.0.99 20060623, gcc 4.2.1-atmel.1.0.3, and uClibc 0.9.29-atmel.1.  
> This is essentially the same as Atmel's buildroot-avr32-v2.1.0.  As soon as I 
> clean stuff up a little, I'll submit patches for this via bugzilla.  Minus 
> this uclibc.inc diff.  I need more expert opinion on this.
> 
> Thanks to all those who helped!
> ---


excellent job, can you supply any patches you have already, i would be
more then happy to bring this up ( again !)

rob_w

Re: Eureka! AVR32 ld-uClibc.so segfault solved

[Khem Raj]

Geoffrey,

Try to build uclibc with V=1 on commandline and check what extra flags
are passed due to this option. I think these flags might be incorrect
for AVR32

Thanks

-Khem


On Wed, Mar 12, 2008 at 1:04 PM, Robert Wörle
<robert@linuxdevelopment.de> wrote:
>
>
>
>  > So I now have a working OE based AVR32 build system, using binutils
>  > 2.17.atmel.0.0.99 20060623, gcc 4.2.1-atmel.1.0.3, and uClibc 0.9.29-atmel.1.
>  > This is essentially the same as Atmel's buildroot-avr32-v2.1.0.  As soon as I
>  > clean stuff up a little, I'll submit patches for this via bugzilla.  Minus
>  > this uclibc.inc diff.  I need more expert opinion on this.
>  >
>  > Thanks to all those who helped!
>  > ---
>
>
>  excellent job, can you supply any patches you have already, i would be
>  more then happy to bring this up ( again !)
>
>  rob_w
>
>
>
>  _______________________________________________
>  Openembedded-devel mailing list
>  Openembedded-devel@lists.openembedded.org
>  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Eureka! AVR32 ld-uClibc.so segfault solved

[Robert Wörle]

Dear Geoffrey , Dear all

I dont get it.
My chain stops at this stage below trying to find external-toolchain
under /usr/local/angstrom/

Can you hint me over this


NOTE: package gcc-cross-initial-4.1.2-r14: task do_populate_staging:
completed
NOTE: package gcc-cross-initial-4.1.2: completed
NOTE: Running task 184 of 591 (ID: 81,
/srv/home/bob/oe/org.openembedded.dev/packages/meta/external-toolchain.bb,
do_populate_staging)
NOTE: package external-toolchain-1.0: started
NOTE: package external-toolchain-1.0-r1: task do_populate_staging: started
NOTE: exceptions.AttributeError:'module' object has no attribute
'get_srcrev' while evaluating:
${@bb.fetch.get_srcrev(d)}
ERROR: function do_stage failed
ERROR: log data follows
(/srv/home/bob/oe/avr32/tmp/work/x86_64-avr32-sdk-angstrom-linux-uclibc/external-toolchain-1.0-r1/temp/log.do_stage.7411)
| The external toolchain could not be found in /usr/local/angstrom/avr32!
NOTE: Task failed:
/srv/home/bob/oe/avr32/tmp/work/x86_64-avr32-sdk-angstrom-linux-uclibc/external-toolchain-1.0-r1/temp/log.do_stage.7411
NOTE: package external-toolchain-1.0-r1: task do_populate_staging: failed
ERROR: TaskFailed event exception, aborting
NOTE: package external-toolchain-1.0: failed
ERROR: Build of
/srv/home/bob/oe/org.openembedded.dev/packages/meta/external-toolchain.bb
do_populate_staging failed
ERROR: Task 81
(/srv/home/bob/oe/org.openembedded.dev/packages/meta/external-toolchain.bb,
do_populate_staging) failed
NOTE: Tasks Summary: Attempted 183 tasks of which 122 didn't need to be
rerun and 1 failed.
ERROR:
'/srv/home/bob/oe/org.openembedded.dev/packages/meta/external-toolchain.bb'
failed


Khem Raj schrieb:
> Geoffrey,
> 
> Try to build uclibc with V=1 on commandline and check what extra flags
> are passed due to this option. I think these flags might be incorrect
> for AVR32
> 
> Thanks
> 
> -Khem
> 
> 
> On Wed, Mar 12, 2008 at 1:04 PM, Robert Wörle
> <robert@linuxdevelopment.de> wrote:
>>
>>
>>  > So I now have a working OE based AVR32 build system, using binutils
>>  > 2.17.atmel.0.0.99 20060623, gcc 4.2.1-atmel.1.0.3, and uClibc 0.9.29-atmel.1.
>>  > This is essentially the same as Atmel's buildroot-avr32-v2.1.0.  As soon as I
>>  > clean stuff up a little, I'll submit patches for this via bugzilla.  Minus
>>  > this uclibc.inc diff.  I need more expert opinion on this.
>>  >
>>  > Thanks to all those who helped!
>>  > ---
>>
>>
>>  excellent job, can you supply any patches you have already, i would be
>>  more then happy to bring this up ( again !)
>>
>>  rob_w
>>
>>
>>
>>  _______________________________________________
>>  Openembedded-devel mailing list
>>  Openembedded-devel@lists.openembedded.org
>>  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

-- 

*Robert Woerle
**Linux Development *

phone: 	+49 (0)821 4442253
mobile: 	+49 179 4744527
email: 	robert@linuxdevelopment.de <mailto:robert@linuxdevelopment.de>
web: 	http://www.linuxdevelopment.de
UStNr. 	102/289/51264









This e-mail message and any files transmitted with it are confidential
property  and are intended only for the person(s) to whom this e-mail is
addressed.  If you have received this e-mail message in error, please
notify the sender immediately by telephone or e-mail and destroy the
original message without making a copy. Thank you.

Re: Eureka! AVR32 ld-uClibc.so segfault solved

[Geoffrey Wossum]

On Wednesday 12 March 2008 03:04:57 pm Robert Wörle wrote:
> > So I now have a working OE based AVR32 build system, using binutils
> > 2.17.atmel.0.0.99 20060623, gcc 4.2.1-atmel.1.0.3, and uClibc
> > 0.9.29-atmel.1. This is essentially the same as Atmel's
> > buildroot-avr32-v2.1.0.  As soon as I clean stuff up a little, I'll
> > submit patches for this via bugzilla.  Minus this uclibc.inc diff.  I
> > need more expert opinion on this.
>
> excellent job, can you supply any patches you have already, i would be
> more then happy to bring this up ( again !)

I need to clean up what I've done and take out all the extraneous changes that 
didn't actually help.  Then test the resulting patches from scratch to make 
sure everything still works.  Hopefully I'll have the patch set ready later 
today.

---
Geoffrey

Re: Eureka! AVR32 ld-uClibc.so segfault solved

[Geoffrey Wossum]

On Wednesday 12 March 2008 08:33:01 pm Khem Raj wrote:

> Try to build uclibc with V=1 on commandline and check what extra flags
> are passed due to this option. I think these flags might be incorrect
> for AVR32

Pass V=1 on which commandline?  I assume we're talking about the uClibc 
compile flags, though.

I knew that ld-uClibc.so was the culprit.  Atmel's buildroot's ld-uClibc.so 
worked, OE's ld-uClibc.so didn't.  How were they different?  uClibc source 
code was the same.  Configuration, slightly different, but making them the 
same didn't fix anything.  Binutils were the same.  gcc was within an 
epsilon.  I even checked the preprocessed ldso source code.  It was the same 
in every way that mattered.  That pretty much just left the compiler options.

Here's what buildroot, which built a working ld-uClibc.so, looked like:
/home/geoff/src/buildroot-avr32-v2.1.0/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-gcc -c 
ldso/ldso/ldso.c -o 
ldso/ldso/ldso.oS -include ./include/libc-symbols.h -Wall -Wstrict-prototypes -fno-strict-aliasing -march=ap -fno-stack-protector -fno-builtin -nostdinc -I./include -I. -msoft-float -std=gnu99 -Os -funit-at-a-time -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/avr32 -I./libpthread/linuxthreads.old/sysdeps/avr32 -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I./libpthread/linuxthreads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -I/home/geoff/src/buildroot-avr32-v2.1.0/toolchain_build_avr32_nofpu/linux/include/ -isystem /home/geoff/src/buildroot-avr32-v2.1.0/build_avr32_nofpu/staging_dir/lib/gcc/avr32-linux-uclibc/4.2.1/include -DNDEBUG -fPIC -DSHARED -DNOT_IN_libc -DIS_IN_rtld -fno-stack-protector -fno-omit-frame-pointer -I./ldso/ldso/avr32 -I./ldso/include -I./ldso/ldso -DUCLIBC_RUNTIME_PREFIX="/" -DUCLIBC_LDSO="ld-uClibc.so.0" -DLDSO_ELFINTERP="avr32/elfinterp.c"

Here's what OE, which did not build a working ld-uClibc.so, looked like:
avr32-angstrom-linux-uclibc-gcc -c ldso/ldso/ldso.c -o 
ldso/ldso/ldso.oS -include ./include/libc-symbols.h -Wall -Wstrict-prototypes -fno-strict-aliasing -isystem/home/geoff/lrs/playpaq/tmp/staging/avr32-angstrom-linux-uclibc/usr/include -fno-stack-protector -fno-builtin -nostdinc -I./include -I. -msoft-float -std=gnu99 -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/avr32 -I./libpthread/linuxthreads.old/sysdeps/avr32 -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I./libpthread/linuxthreads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -I/home/geoff/lrs/playpaq/tmp/staging/avr32-angstrom-linux-uclibc/usr/include/ -isystem /home/geoff/lrs/playpaq/tmp/cross/lib/gcc/avr32-angstrom-linux-uclibc/4.2.1/include -DNDEBUG -fPIC -DSHARED -DNOT_IN_libc -DIS_IN_rtld -fno-stack-protector -fno-omit-frame-pointer -I./ldso/ldso/avr32 -I./ldso/include -I./ldso/ldso -DUCLIBC_RUNTIME_PREFIX="/" -DUCLIBC_LDSO="ld-uClibc.so.0" -DLDSO_ELFINTERP="avr32/elfinterp.c"


Ignoring the obvious differences in pathing, the buildroot command line has 
the following additional options:
 * -Os
 * -fno-strength-reduce 
 * -fno-tree-dominator-opts 
 * -fno-tree-loop-optimize 
 * -funit-at-a-time 
 * -march=ap 

I thought -march=ap was probably the magic option.  I figured out uclibc.inc 
was overriding it by passing CPU_CFLAGS="${CFLAGS}".  When I got rid of that 
override, -march=ap was being passed to gcc now, but ld-uClibc.so was still 
broken.  So I got rid of the OPTIMIZATION=' ' override as well.  The BR and 
OE command line switches now matched, except of course for the paths.  With 
that change, ld-uClibc.so now works.  

I'm not sure which of the other flags is the magical one.  This does match my 
experience with other voodooish pieces of code, like bootloaders, being 
extremely sensitive to compilation flags.

As an added bonus, the libc.so and friends are much smaller.  On a cache 
cramped processor like the AVR32, this probably also means faster, although 
I'm not inclined to actually benchmark it right now.

So, for anyone who's still paying attention, why are CPU_CFLAGS and 
OPTIMIZATIONS being overridden in uclibc.inc?  If this is needed to make some 
other platform work, it seems like the wrong way to go about it.  Especially 
since it breaks the AVR32.  Obviously, anything that breaks what I'm trying 
to do is the wrong way to do it ;)

---
Geoffrey

Re: Eureka! AVR32 ld-uClibc.so segfault solved

[Geoffrey Wossum]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Thursday 13 March 2008 03:40:34 am Robert Wörle wrote:
> Dear Geoffrey , Dear all
>
> I dont get it.
> My chain stops at this stage below trying to find external-toolchain
> under /usr/local/angstrom/
>
> Can you hint me over this

Don't know enough about BitBake / OE to really comment on the problem 
directly.  I'm not trying to use an external toolchain.  I decided I'd rather 
fix the toolchain in OE than try to use an external toolchain.

I'm attaching my local.conf file for the AT32STK1000 board.  Of course, until 
I get the rest of my toolchain patches submitted, it may not help you out too 
much.  I think with what's currently in org.openembedded.dev, it will at 
least build a file system that'll boot until it gets to init, and then 
segfault.

Watch out for the PRJROOT variable I used in it.  I have a script I source 
when I start working on my project that sets this environment variable.

---
Geoffrey
  

[-- Attachment #2: local.conf --]
[-- Type: text/plain, Size: 7647 bytes --]

#
# OpenEmbedded local configuration file (sample)
#
# Please visit the Wiki at http://openembedded.org/ for more info.
#
#
# Be SURE to read this file in its entirety and the GettingStarted page on the
# wiki before proceeding.
#
# Once you have done that, remove the line at the end of this
# file and build away.
# 
# WARNING: lines starting with a space (' ') will result in parse failures.
# Remove '# ' from commented lines to activate them.
#
# NOTE: Do NOT use $HOME in your paths, BitBake does NOT expand ~ for you.  If you
# must have paths relative to your homedir use ${HOME} (note the {}'s there
# you MUST have them for the variable expansion to be done by BitBake).  Your
# paths should all be absolute paths (They should all start with a / after
# expansion.  Stuff like starting with ${HOME} or ${TOPDIR} is ok).

# Use this to specify where BitBake should place the downloaded sources into
#DL_DIR = "${HOME}/sources"
DL_DIR = "${PRJROOT}/sources"

# Delete the line below. Then specify which .bb files to consider for
# your build. Typically this will be something like BBFILES = "/path/to/openembedded/packages/*/*.bb"
BBFILES = "${PRJROOT}/org.openembedded.dev/packages/*/*.bb"

# Use the BBMASK below to instruct BitBake to _NOT_ consider some .bb files
# This is a regulary expression, so be sure to get your parenthesis balanced.
BBMASK = ""

# Uncomment this if you want to use a prebuilt toolchain. You will need to
# provide packages for toolchain and additional libraries yourself. You also
# have to set PATH in your environment to make sure BitBake finds additional binaries.
# ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}gcc virtual/libc"

# Uncomment this if you're building for an arch that uses emulated locale 
# generation under qemu (mainly arm glibc) and have an external gcc 3.x compiler
# that OE recognises. This will mean the gcc-native build is skipped, speeding 
# builds up.
# ASSUME_PROVIDED += "gcc3-native"

# Uncomment this if you are building Linux 2.4 Embedix kernels.
# i.e. openzaurus-sa-2.4.18 and openzaurus-pxa-2.4.18 - and don't forget
# to rename the binaries as instructed in the Wiki.
# Most users do not need this anymore thankfully!
# ASSUME_PROVIDED += "virtual/arm-linux-gcc-2.95"

# Select between multiple alternative providers, if more than one is eligible.
PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie"
PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-x11"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-initial:gcc-cross-initial"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}g++:gcc-cross"

#PREFERRED_PROVIDER_virtual/avr32-angstrom-linux-uclibc-libc-for-gcc = "uclibc"
PREFERRED_VERSION_linux = "2.6.23"


# Uncomment this to specify where BitBake should create its temporary files.
# Note that a full build of everything in OpenEmbedded will take GigaBytes of hard
# disk space, so make sure to free enough space. The default TMPDIR is
# <build directory>/tmp
# Don't use symlinks in in the path to avoid problems
# TMPDIR = /usr/local/projects/oetmp

# Uncomment this to specify a machine to build for. See the conf directory
# for machines currently known to OpenEmbedded. This will automatically take care
# of TARGET_ARCH
# MACHINE = "c7x0"
MACHINE = "at32stk1000"
#MACHINE = "atngw100"

# Use this to specify the target architecture. Note that this is only
# needed when building for a machine not known to OpenEmbedded. Better use
# the MACHINE attribute (see above)
# TARGET_ARCH = "arm"

# Use this to specify the target operating system.  The default is "linux",
# for a normal linux system with glibc. Set this to "linux-uclibc" if you want
# to build a uclibc based system.
# Normally the DISTRO of your choosing will take care of this 
# TARGET_OS = "linux"
TARGET_OS = "linux-uclibc"

# Uncomment this to select a distribution policy. See the conf directory
# for distributions currently known to OpenEmbedded.
# Although it no longer contain version number in the (file-)name
# openzaurus-unstable is a so called "versioned"  distro, i.e. they 
# explicitely select specific versions of various packages.
# Stay away from unversioned distros unless you really know what you are doing
DISTRO = "angstrom-2008.1"

# Only uClibc supports the AVR32, so we must get a uClibc based Angstrom
ANGSTROM_MODE = "uclibc"



# So far, angstrom.conf sets ENABLE_BINARY_LOCALE_GENERATION
# to generate binary locale packages at build time using qemu-native and
# thereby guarantee i18n support on all devices. If your build breaks on 
# qemu-native consider disabling ENABLE_BINARY_LOCALE_GENERATION (note that
# this breaks i18n on devices with less than 128MB RAM) or installing
# a working third-party qemu (e.g. provided by your distribution) and
# adding qemu-native to ASSUME_PROVIDED. Caveat emptor, since third-party
# qemus lack patches needed to work with various OE targets.
# ENABLE_BINARY_LOCALE_GENERATION = "0"
# ASSUME_PROVIDED += "qemu-native"

# If ENABLE_BINARY_LOCALE_GENERATION is set to "1", you can limit locales
# generated to the list provided by GLIBC_GENERATE_LOCALES. This is huge
# time-savior for developmental builds. Format: list of locale.encoding pairs
# with spaces as separators.
# GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 de_DE.UTF-8"

# Uncomment this to select a particular major kernel version if the MACHINE setting
# supports more than one major kernel version. Currently this is suported by the
# following MACHINE types: poodle, tosa and simpad.
# MACHINE_KERNEL_VERSION = "2.6"

# Uncomment one of these to build packages during the build process.
# This is done automatically if you set DISTRO (see above)
# INHERIT = "package_ipk"
# INHERIT = "package_tar"

# Add the required image file system types below. Valid are 
# jffs2, tar(.gz|bz2), cpio(.gz), cramfs, ext2(.gz), ext3(.gz)
# squashfs, squashfs-lzma
IMAGE_FSTYPES = "ext3 jffs2 tar"

# Uncomment this to disable the parse cache (not recommended).
# CACHE = ""

# Uncomment this if you want BitBake to emit debugging output
BBDEBUG = "yes"

# Uncomment these two if you want BitBake to build images useful for debugging. 
# Note that INHIBIT_PACKAGE_STRIP needs a package format to be defined.
# Also note that OE now produces -dbg packages which contain debugging symbols.
# DEBUG_BUILD = "1"
# INHIBIT_PACKAGE_STRIP = "1"

# Uncomment these to build a package such that you can use gprof to profile it.
# NOTE: This will only work with 'linux' targets, not
# 'linux-uclibc', as uClibc doesn't provide the necessary
# object files.  Also, don't build glibc itself with these
# flags, or it'll fail to build.
#
# PROFILE_OPTIMIZATION = "-pg"
# SELECTED_OPTIMIZATION = "${PROFILE_OPTIMIZATION}"
# LDFLAGS =+ "-pg"

# Uncomment this to enable parallel make.
# This allows make to spawn mutliple processes to take advantage of multiple 
# processors. Useful on SMP machines. This may break some packages - we're
# in the process of marking these so let us know if you find any.
PARALLEL_MAKE = "-j 3"

# Uncomment this if you want BitBake to emit the log if a build fails.
BBINCLUDELOGS = "yes"

# Specifies a location to search for pre-generated tarballs when fetching
# a cvs:// URI. Outcomment this, if you always want to pull directly from CVS.
#CVS_TARBALL_STASH = ""

# EDIT THIS FILE and then remove the line below before using!
#REMOVE_THIS_LINE:="${@bb.fatal('Read the comments in your conf/local.conf')}"

Re: Eureka! AVR32 ld-uClibc.so segfault solved

[Geoffrey Wossum]

On Wednesday 12 March 2008 02:50:09 pm Geoffrey Wossum wrote:

> I just tracked down the culprit for my AVR32 system always segfaulting
> whenever ld-uClibc.so ran (usually as soon as the kernel attempted to run
> the init process).

I just submitted all my patches for the AVR32 to OE's bugzilla.  They are 
attachments under bug #4062.

These patches should let you build a bootable Angstrom 2008.1 AVR32 image 
using gcc-4.2.1-atmel.1.3.0 and uClibc-0.9.29-atmel.1.

All of the patches are straight forward, except for patch to uclibc.inc 
(attachment #8196).  Some one who knows more about why CPU_CFLAGS and 
OPTIMIZATION were being overridden by uclibc.inc needs to comment about the 
effect this change would have on other platforms.  This is really the 
important patch, since without it you can't build a working ld-uClibc.so.

---
Geoffrey

Re: Eureka! AVR32 ld-uClibc.so segfault solved

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Geoffrey Wossum schreef:
| On Wednesday 12 March 2008 02:50:09 pm Geoffrey Wossum wrote:
|
|> I just tracked down the culprit for my AVR32 system always segfaulting
|> whenever ld-uClibc.so ran (usually as soon as the kernel attempted to run
|> the init process).
|
| I just submitted all my patches for the AVR32 to OE's bugzilla.  They are
| attachments under bug #4062.

I applied all patches from #4062 and fixed some avr32 gcc-cross and
mplayer issues while I was at it.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH2nd1MkyGM64RGpERAoaBAJ0dpXfKVOuWuWQoUP9q/yHQiK3wKwCdGAEl
qxbBG5jckHIjPPzHBEzscsk=
=Azmm
-----END PGP SIGNATURE-----

Re: Eureka! AVR32 ld-uClibc.so segfault solved

[Leon Woestenberg]

Hello Geoffrey,

On Thu, Mar 13, 2008 at 8:17 PM, Geoffrey Wossum <geoffrey@pager.net> wrote:
> On Wednesday 12 March 2008 02:50:09 pm Geoffrey Wossum wrote:
> ...
>  I just submitted all my patches for the AVR32 to OE's bugzilla.  They are
> ...
>  All of the patches are straight forward, except for patch to uclibc.inc
>  (attachment #8196).  Some one who knows more about why CPU_CFLAGS and
>  OPTIMIZATION were being overridden by uclibc.inc needs to comment about the
>  effect this change would have on other platforms.  This is really the
>  important patch, since without it you can't build a working ld-uClibc.so.
>
Good question. I had a similar question about something that wasn't
trivial in the (uclibc) bitbake recipe.

Obviously, we need to comment the non-trivial parts a bit better while
we review and/or commit to the more complex parts of the OE metadata,
such as the toolchain.

Thanks for the work on the AVR32,

Regards,
-- 
Leon

Re: Eureka! AVR32 ld-uClibc.so segfault solved

[Geoffrey Wossum]

On Friday 14 March 2008 12:36:46 pm Leon Woestenberg wrote:
> Hello Geoffrey,
>
> On Thu, Mar 13, 2008 at 8:17 PM, Geoffrey Wossum <geoffrey@pager.net> wrote:
> > On Wednesday 12 March 2008 02:50:09 pm Geoffrey Wossum wrote:
> > ...
> >  I just submitted all my patches for the AVR32 to OE's bugzilla.  They
> > are ...
> >  All of the patches are straight forward, except for patch to uclibc.inc
> >  (attachment #8196).  Some one who knows more about why CPU_CFLAGS and
> >  OPTIMIZATION were being overridden by uclibc.inc needs to comment about
> > the effect this change would have on other platforms.  This is really the
> > important patch, since without it you can't build a working ld-uClibc.so.
>
> Good question. I had a similar question about something that wasn't
> trivial in the (uclibc) bitbake recipe.

I'm beginning to think no one actually remembers why this change was made.  I 
located the comment for this change in monotone (it's from 2005-08-11):

---begin--
This set of changes ensures that TARGET_CC_ARCH is passed reliably to all 
packages in a build.  The change fixes problems in the following packages:
<snip>
 | |   uclibc{,-initial}_0.9.27
| | | TARGET_CC_ARCH added to the do_compile.  For the do_stage step the
| | | build actually compiles target code (make utils), but this will not
| | | accept a CC with whitespace.  The TARGET_CC_ARCH flags have therefore
| | | been added to CFLAGS (a bit ugly, but it works).
---end---

My current opinion is that this may have been change made to help debug this 
problem, but wasn't really part of the solution and wasn't intended to be in 
the patch.
 
Even if this was really a fix for a problem on another platform, since it 
breaks at least one platform (AVR32), it wasn't an optimal solution.   Since 
the patch to stop overriding CPU_CFLAGS and OPTIMIZATIONS was applied, I 
guess we'll found out soon if another platform need this :)

---
Geoffrey