New Linux toolchain w. avr-libc-1.7.0

Go To Last Post
62 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guyzz

Quote:
Edit: 18-Nov-2010
Remember to replace the original (installed) util/delay.h
With the one from here
https://www.avrfreaks.net/index.p...

Else you are hit by a nasty delay bug.

New .deb files for Ubuntu 10.04 i386 and X64

Get the packages here.
http://www.wrightflyer.co.uk/avr...

Only change is rebuild with avr-libc-1.7.0 ....

I suggest that you remove previous .deb packages (synaptic), before installing this one. I haven't tested what happens if installing a new package on top of an old package.

/Bingo

Ps: Will prob do an i386 build on 8.04 soon.

Attachment(s): 

Last Edited: Thu. Nov 18, 2010 - 08:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I suggest that you remove previous .deb packages (synaptic)

I generally just use: "dpkg -r name_of_package.deb". In fact what I generally do is:

root@DevSystem:~/kontrollerlab-0.8.0-beta1# dpkg --get-selections | grep avr
avr-gcc-4.3.3-avrfreaks-23-feb-2010-special	install

and then:

==================================================================================

root@DevSystem:~/kontrollerlab-0.8.0-beta1# dpkg -r avr-gcc-4.3.3-avrfreaks-23-feb-2010-special

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Cliff

Thats also a way to do it , if you're a CLI guru :-)

Btw: Do you like Kontrollerlab ?

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Btw: Do you like Kontrollerlab ?

Never seen it because I couldn't build it ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://blog.fh-kaernten.at/wehr/...

Does gcc 4.4.4 support 24bit memory pointer?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Works great on my Ubuntu 10.04 installation, once I managed to get it to install. Trying to uninstall the previous package caused my package manager to freak out about /usr/ not being empty (was it trying to delete /usr/? I hope not!) but after some fixing on my part it all works once again - and I can build my LUFA packages without avr-libc errors now!

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Dean

There is s "quirk" , when you try to uninstall the package.

It complains about /usr , not being empty.
But as i have read ... it's just a complain "notice" , it doesn't try to delete anything it didn't put there

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Affirm. Bingo an I spent some time on dpkg -i and dpkg -r tests and the warning about /usr is definitely benign.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm assuming that this 1.7.0 code has the new "improved" _delay_xx() routines in which no longer work properly?
(Code incorrectly calls __builtin_delay_cycles() with incorrect argument)

Which may mean that the release should be pulled until this is fixed.

(Its a very simple/easy fix)

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bill,

Did you read this thread:

https://www.avrfreaks.net/index.p...

it's clearly the case that util/delay.h has been broken. The key issue is who's going to report the fault so it gets fixed in 1.7.1

(what wasn't clear to me was who had screwed it in the first place - whoever did the work to implement the _builtin_cycles() variant of _delay_*() should clean up their own mess - it cannot have been tested before release which is unforgiveable)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did read the thread. That is what triggered me to post my comment above.
Perhaps my sarcasm didn't come across.

When I said "release" I meant Bingos .deb package.
My thought was that it might be a good idea to pull Bingo's most recent .deb files until this is corrected.

I reviewed the new code and looked
at the log messages in the repository.
I posted my comment in this thread as kind of a warning to folks to take pause and think before they upgrade to this new version of the compiler, because the delay functions were broken.

As far as posting a bug on Savanah, I'll be happy to do that.
Heck, I'd even go in and fix it if I had access to the repository. Perhaps if I post a corrected version of the header file it will accelerate its correction.
The _delay_xx() code is something that I'm very familiar with and has been a real thorn in my side for quite some time as it wasn't good enough to really use for low level h/w delays because of its granularity and rounding errors.
The updated code for using the builtin delay cycles routine is really quite trivial - once you decide which way to round the cycles.
It can even be done with a very small 1 line function like macro instead of an in-line function.

So what still remains a bit unknown is which way
to round the cycle calculation.
(I'll spare everyone the discussion of this here)

In the larger picture, I think the delay functions/macros need a larger re-do anyway to provide better control over the delay calculations to include things like rounding. (up, down, vs closest etc...)
(All things I've been proposing for quite some time now).

UPDATE:
Bug posted on savannah: https://savannah.nongnu.org/bugs/index.php?30363

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would not be that concerned about precision.

Using C (or any other higher level language), you agree to give up control (including control over timing) in exchange for comfort. If you want to reclaim control, fall back to asm.

Thus, I'd generally go for "least length" delays, as they do the least harm, and update documentation accordingly.

All this said, I do appreciate your contribution.

Jan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Bill,

Did you read this thread:

https://www.avrfreaks.net/index.p...

it's clearly the case that util/delay.h has been broken. The key issue is who's going to report the fault so it gets fixed in 1.7.1

(what wasn't clear to me was who had screwed it in the first place - whoever did the work to implement the _builtin_cycles() variant of _delay_*() should clean up their own mess - it cannot have been tested before release which is unforgiveable)

Guyzz

The "builtins.h" is created by EW in a WinAVR avr-libc patch , and when i build for linux using the 1.6.8 source from savannah , the linux vers didn't include a builtin.h.

I grabbed a builtin.h from my "special static" build , based on winavr patches , and included the file in the buildscript , with a comment that the user could copy it to the right place.

I haven't checked if avr-libc-1.7.0 does create that file now , or if you still have to run that Winavr-Patch. If the latter , then there is no builtin.h in the new toolchain , other than the one from 1.6.8 that i included in the buildscript , from the "special" build. You still have to copy it manually to the right place.

I haven't access to a Linux machine with the new 1.7.0 build right now , so i can't check if the "builtin.h" is included at all. Maybe someone else can check , and verify if the .deb packages on Cliff's server are affected , or if there is a builtin.h at all.

Edit:
If the contents of delay.h has changed in 1.7.0 , i'd expect the linux build to be "hit".
The above was all about creation of the builtins.h file , witch i'm not sure is created by the avr-libc source , but by a WinAVR patch that isn't included.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

so i can't check if the "builtin.h" is included at all. Maybe someone else can check , and verify if the .deb packages on Cliff's server are affected , or if there is a builtin.h at all.

Unpacking avr-gcc-4.3.4-avrfreaks-30-jun-2010-u10.04.i386 (from avr-gcc-4.3.4-avrfreaks-30-jun-2010-u10.04.i386.deb) ...
Setting up avr-gcc-4.3.4-avrfreaks-30-jun-2010-u10.04.i386 (0.1) ...
root@DevSystem:/win/DDrive# cd /usr/local/avr/
root@DevSystem:/usr/local/avr# find . -name built\*.h
./avr/include/avr/builtins.h

I was going to build a test program and check the .lss for __builtin but it turns out the VM I was using is 9.10 not 10.04 and I have the "missing GLIBC 2.11" problem so I'm just upgrading the VM to Lucid.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nevertheless, does not include :

wrote:

#if __HAS_DELAY_CYCLES && defined(__OPTIMIZE__)
	extern void __builtin_avr_delay_cycles(unsigned long);
	__builtin_avr_delay_cycles(__tmp);


JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah yes, I see:

root@DevSystem:/usr/local/avr/avr/include/util# grep built *.h
delay.h:	extern void __builtin_avr_delay_cycles(unsigned long);
delay.h:	__builtin_avr_delay_cycles(__tmp);
delay.h:	extern void __builtin_avr_delay_cycles(unsigned long);
delay.h:	__builtin_avr_delay_cycles(__tmp);

in which case this delay fault is benign for this .deb unless someone makes the error of including avr/builtin.h above util/delay.h - which seems unlikely.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't quite understand your reasoning, Cliff.

It would not affect an avr-libc-1.7.0 build only if __HAS_DELAY_CYCLES is not defined. Whether it includes builtin.h or not is irrelevant - the function itself, being a builtin, is - ehm - built into the compiler. Its source is in the avr-gcc patches, see e.g. [WinAVR20100110]\source\avr\gcc\4.3.3\61-gcc-4.3.3-builtins_v6.patch (I don't know where is the source repository for the actual ones).

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jan,

My bad! Because I'd already seen:

#ifndef _AVR_BUILTINS_H_
#define _AVR_BUILTINS_H_

#ifndef __HAS_DELAY_CYCLES
#define __HAS_DELAY_CYCLES 1
#endif

I assumed (yes I know!) that this was the only likely place it may be defined and the fact that builtins.h were not included would mean that the "new" code in delay.h would not be activated. But on looking at delay.h I now see it also has:

#ifndef _UTIL_DELAY_H_
#define _UTIL_DELAY_H_ 1

#ifndef __HAS_DELAY_CYCLES
#define __HAS_DELAY_CYCLES 1
#endif

(Personally I'm not a fan of macros that can be defined in multiple places). This does kind of raise the question as to why delay.h later has this test:

#if __HAS_DELAY_CYCLES && defined(__OPTIMIZE__)
        extern void __builtin_avr_delay_cycles(unsigned long);
        __builtin_avr_delay_cycles(__tmp);
#else
...

I can understand the test for __OPTIMIZE__ but why's it bothering to test __HAS_DELAY_CYCLES when it's #defined at the top of the very same .h file? Just trying to be deliberately confusing for a bear of very little brain like me?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
I would not be that concerned about precision.

Using C (or any other higher level language), you agree to give up control (including control over timing) in exchange for comfort. If you want to reclaim control, fall back to asm.

Thus, I'd generally go for "least length" delays, as they do the least harm, and update documentation accordingly.

All this said, I do appreciate your contribution.

Jan

But when people give up full control, they shouldn't necessarily expect an implementation in C to provide inferior functionality to what the C language is capable of providing.

As far as "least delay" doing the "least harm", that isn't necessarily the case. In my situation - which shouldn't be that uncommon, "least delay" makes the code that uses it fail in many situations and this is why I would argue against "least length" delays - see the bug report.
In my mind the main reason to be using these busy/spinloop type of delays is because a hardware timer can't provide super short delays for things like hardware setup times. And it is these type/length of delays where breaks down the most and has the most deviation between what is possible and what is provided.

Again - See the bug report for further details on why I believe that rounding cycle up is "better".

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am one of the at the moment 13 people in the world who have downloaded the link at the top of this page and am now trying to follow it.
I beleive I was the 13th.
It is on a new installation so I dont have the problems of removing old copies as described above.

The computer is not on line so I can not follow the script exactly but using it manually.

First problem I noticed was that in "get-patches.sh" two files "patch-xmega" and "patch-newdevices" occure with the same name in the first two tarballs but diff tells me they are not the same file.

This is as far as I have come but I would like to hear from anyone who has come further.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John,

Before you waste more of your own time can you confirm that your Linux distribution is not able to install .deb's ? It's a whole lot easier to use the output of the script that Bingo already built for you if you can.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My installation is not a distribution.
It was built from original source code.
The instructions are here

http://cross-lfs.org/view/1.1.0/

I want to keep to the original theme of a pure
source code installation.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I want to keep to the original theme of a pure
source code installation.

Now I understand the picture in your avatar :lol:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The tarballs follow the freebsd repos and have different urls
but same filename. If you want to play manual play All Lines

Edit: Then you'll see that the files are extracted to different dirs , and later used for patching.

Btw: I dont see why you couldn't run the script , it's pure "bash"

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Btw: I dont see why you couldn't run the script , it's pure "bash"

As mentioned above the computer is not on line so I dont get much fun from wget.

I can of course download everything on another computer and copy.
Read the script and use command line.

I will try to explain a little more fully.

The contents of
http://www.freebsd.org/cgi/cvswe...

patch-aa patch-as-dwarf-avrstudio patch-coff-avr patch-newsections
patch-as-dwarf patch-avr-size patch-newdevices patch-xmega

The contents of
http://www.freebsd.org/cgi/cvswe...

patch-avr-libgcc.S patch-builtins
patch-bug11259 patch-disable-ssp
patch-bug18145 patch-libiberty-Makefile.in
patch-bug19636-24894-31644-31786 patch-newdevices
patch-bug33009 patch-param-inline-call-cost
patch-bug34210-35508 patch-xmega
patch-bug35013 patch-xx-os_main

I can see that the urls must be different.

What I would like to point out is that both tarballs contain files by the name of "patch-xmega" and "patch-newdevices"

The diff command tells me that these are not the same file.
If the script were to be used as is the files from avr-binutiles would be overwritten by those from avr-gcc.

I was typing in at the command line and asked if I wanted to overwrite these files.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Notice these lines before the wget , haven't you wondered what they do ?
Maybe ... creating a "separate" dir for the downloaded file.

#############################################################
# Binutils
#############################################################
cd ${base}
cd ${patchdir}
mkdir ${binutilsbase}
cd ${binutilsbase}
rm -fr *
#

Please don't do half a "script" ....

And the script has to obey the way patchdata is stored in the FreeBSD repos , where all patchfiles have the same name.
But is expected to be extracted in different dir's.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohnWalton wrote:
Quote:

I can of course download everything on another computer and copy.
Read the script and use command line.

Btw : Sounds like a nice idea.
Run getfiles & getpatches , and copy the whole dir to the "other machine".

You'll need the packages from "pre-reqs" or their eqvivalents installed also.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could setup apache2 and let wget operate from 127.0.0.1 (just map everything to the local machine with /etc/hosts)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Many thanks Bingo I can see it all a bit more clearly now.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of my ideas in all this was to put a set of instructions back on the BCLFS site here

http://cblfs.cross-lfs.org/index.php/Main_Page

Sorry I missed a few points in Bingos script.

Many thanks Cliff for the above idea.
I have been wondering how to use my own machine as its own server.
The problem comes in installing all the Xorg files.
If you take a quick look here you get the point.

http://cblfs.cross-lfs.org/index...

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The problem comes in installing all the Xorg files.
If you take a quick look here you get the point

Been There, Done That, Worn the T-Shirt!

I've had to build Xorg from source in order to get early access to Intel DRM video drivers which were not in the Debian packaged Xorg in the Ubuntu repositories, so I feel your pain.

I still get daily emails from the Xorg developers mailing list:

http://lists.freedesktop.org/mai...

it's undoubtedly the best place to get help about building Xorg from sources.

The main problem with Xorg is that when you try to ./configure it you find you have to have about 50 other dependencies before you can attempt to build and, as with all these things, trying to work out the versions that actually work for libX, libY or libZ can be an utter nightmare.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was able to run the "get-patches.sh" script by simply changing "wget" to "cp" and renaming the patch tarballs in ${base}.

For my next endevour I tried to run the "buildavr-no-insight.sh" script.
It came down with the following last words.

Quote:
Patching with /sources/avr/make-avr-gcc/patches/binutils-2.20/
patch_binutils.tar.gz

patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.
(./buildavr-no-insight.sh) binutils patching failed.

To me it seems just a little odd to have a tarball in the patch directory and I am not sure that the "patch" command knows how to deal with it.
I may be looking at this the wrong way again and would appreciate some comments before I proceed.

John

If all else fails, read the instructions.

Last Edited: Tue. Jul 13, 2010 - 12:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John,

Is the machine you are trying to do this on the ONLY PC you have access to? If not then install Oracle(Sun)'s VirtualBox and create a virtual machine and install Ubuntu into it (make the HDD about 8GB). Then run Bingo's scripts within that to see what happens in the "it just works" case which will give you something to compare against when you are trying to diagnose anything that doesn't work on your own system. When finished just delete the virtual machine+drive and get your 8GB back.

I find VM's a great way for "trying stuff" because yo can completely screw up the entire "PC" then just throw it away and start over without any damage to your normal development machines, including the one where the VM is being run.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Is the machine you are trying to do this on the ONLY PC you have access to?

No, I have a whole collection.

I will try to explain.
The last winter here was hard and I spent my evenings building an installation from source code.
I have copied the installation to some other machines by simply taking the hard disk out of the machine I built on and putting it in another and copying to that machines hard disk.
None of these are the ones that I use. Of the ones that I use for avr I have avr-gcc 4.1.1 avr-glibc 1.4.5
which I installed when it was current but getting old now and can not be used with the latest devices. Again there are three of these. One at work one at home and one back up.
When I do an installation I make the first partition a boot partition and that solves many problems.

I plan to spend next winter evenings putting on Xorg.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have now figured out what went wrong.
Will report back.

john

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I have moved up a few levels of confusion and the "buildavr-no-insight.sh" script bauks at one of the patches.

Quote:
tail /tmp/buildavr.log

gcc-4.3.4/install-sh
gcc-4.3.4/libtool-ldflags
gcc-4.3.4/ylwrap
gcc-4.3.4/NEWS
gcc-4.3.4/MD5SUMS
(./buildavr-no-insight.sh) patching GCC source
Patching with /sources/avr/make-avr-gcc/patches/gcc-4.3.4/patch-avr-libgcc.S
./buildavr-no-insight.sh: line 200: 4922 Segmentation fault patch -p0 < $file
(./buildavr-no-insight.sh) gcc patching failed


Anyone else in the world had this?

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have never seen this reported before

And it "smells" a bit of the patch program getting "mad"

You aren't running out of diskspace ?
The sources takes up 500MB+ , when extracted

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The section around line 200 is this one (for file ...) is line 200
And it's where gcc is being patched with all files in the "dir"

#
for file in $patchdir/${gccbase}/*; do
    echo "Patching with $file"
    patch -p0 < $file
    cerror "gcc patching failed"
done

#

Are you having the right permissions ?
I normally build with sudo ./build.....

Edit:

Does the contents of the file :
/sources/avr/make-avr-gcc/patches/gcc-4.3.4/patch-avr-libgcc.S

Look normal or has it been garbled ?

The start should look like this :

diff -ur ../gcc-4.3.4.orig/gcc/config/avr/avr.c ./gcc/config/avr/avr.c
--- ../gcc-4.3.4.orig/gcc/config/avr/avr.c	2008-06-15 23:32:29.000000000 +0200
+++ ./gcc/config/avr/avr.c	2009-10-02 14:27:56.000000000 +0200
@@ -127,7 +127,8 @@
   { 0, 0, 1, 1, 0, 0, 0, 0, "__AVR_ARCH__=35"  },
   { 0, 1, 0, 1, 0, 0, 0, 0, "__AVR_ARCH__=4"   },
   { 0, 1, 1, 1, 0, 0, 0, 0, "__AVR_ARCH__=5"   },
-  { 0, 1, 1, 1, 1, 1, 0, 0, "__AVR_ARCH__=51"  }
+  { 0, 1, 1, 1, 1, 1, 0, 0, "__AVR_ARCH__=51"  },
+  { 0, 1, 1, 1, 1, 1, 1, 0, "__AVR_ARCH__=6"   }
 };
 
 /* These names are used as the index into the avr_arch_types[] table 
@@ -144,7 +145,8 @@
   ARCH_AVR35,
   ARCH_AVR4,
   ARCH_AVR5,
-  ARCH_AVR51
+  ARCH_AVR51,
+  ARCH_AVR6
 };

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An interesting idea. This is at the point where it stopped. All the sources are installed in /usr/local/avr/source.

Quote:
df

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hdb4 3927769 2610983 1113564 71% /
shm 125332 0 125332 0% /dev/shm
/dev/sda1 125002 0 125002 0% /media/memory

So I have about 1GB left.

I did not use the "buidinsight.sh" script. Would this matter?

I have a larger disk in another PC with the intention of copying over and building Xorg on that but if you think this is the problem I will copy over now. I was trying to get a really good text mode only installation first.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Are you having the right permissions ?

I am running as root.
I have not put any users on yet.

Permissions on all patch files
-rw-r--r--

The patching of avarice and binutils went well.
I never changed permissions on the patch files.

Quote:

head patch-avr-libgcc.S

diff -ur ../gcc-4.3.4.orig/gcc/config/avr/avr.c ./gcc/config/avr/avr.c
--- ../gcc-4.3.4.orig/gcc/config/avr/avr.c 2008-06-15 23:32:29.000000000 +0200
+++ ./gcc/config/avr/avr.c 2009-10-02 14:27:56.000000000 +0200
@@ -127,7 +127,8 @@
{ 0, 0, 1, 1, 0, 0, 0, 0, "__AVR_ARCH__=35" },
{ 0, 1, 0, 1, 0, 0, 0, 0, "__AVR_ARCH__=4" },
{ 0, 1, 1, 1, 0, 0, 0, 0, "__AVR_ARCH__=5" },
- { 0, 1, 1, 1, 1, 1, 0, 0, "__AVR_ARCH__=51" }
+ { 0, 1, 1, 1, 1, 1, 0, 0, "__AVR_ARCH__=51" },
+ { 0, 1, 1, 1, 1, 1, 1, 0, "__AVR_ARCH__=6" }

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have 1G left , then i don't think diskspace is an issue.

avrinsight.sh is just for building avrinsight/gdb , and can be run independantly of the "no-insight" script.
In fact it doesn't even need the avr-toolchain to be build. But i seem to remember it needs some x-headers , and prob xwindows installed for compile. You could just build "plain" gdb , it hasn't got the same dependancies as insight/gdb.

I'd say your patch is "weird"

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'd say your patch is "weird"

Then I will have another download and compare.

The size of my patch is 10548.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I meant the patch program.
/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just for a test I copied the patch to /usr/local/avr/source/gcc-4.3.4/ and tried the patch command manually.

patch -p0 < patch-avr-libgcc.S

Worked fine.
Output was.

patching file ./gcc/config/avr/avr.c
patching file ./gcc/config/avr/avr.h
patching file ./gcc/config/avr/avr.md
patching file ./gcc/config/avr/libgcc.S
patching file ./gcc/config/avr/t-avr

Well any guesses.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not really
your command its shorter and doesnt contain slashes
for the patchfile thats it

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But btw could it be bash thats seg faulting?
It actually seems like the patch command isnt excecuted
as the $file isnt expanded

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But btw could it be bash thats seg faulting?

Could be. I have not really used this installation for anything exept install more software.

Can you think of anything I could put in the script to give a more verbose output?

Did I get the correct response when I tried manually?
If so it can not be things like no disk space bad patch or patch command.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have a core file around you can check with

file core

what crashed. Unfortunately most people and distributions turn of core file generation, thinking it is useless.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did not know anything about core dump files until I read post above.

I can not find anything which either allows or blocks core dump files and I will contact the developers. I am on the mail list there.

It crashes at one particular point in Bingos script as mentioned above.
Same point always on several attempts.

Many thanks

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ArnoldB wrote:
If you have a core file around you can check with

file core

what crashed. Unfortunately most people and distributions turn of core file generation, thinking it is useless.


file core*

If he has one, he might have dozens of core files lying around,
each with a different numerical suffix.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Jan,

My bad! Because I'd already seen:

#ifndef _AVR_BUILTINS_H_
#define _AVR_BUILTINS_H_

#ifndef __HAS_DELAY_CYCLES
#define __HAS_DELAY_CYCLES 1
#endif

I assumed (yes I know!) that this was the only likely place it may be defined and the fact that builtins.h were not included would mean that the "new" code in delay.h would not be activated. But on looking at delay.h I now see it also has:

#ifndef _UTIL_DELAY_H_
#define _UTIL_DELAY_H_ 1

#ifndef __HAS_DELAY_CYCLES
#define __HAS_DELAY_CYCLES 1
#endif

(Personally I'm not a fan of macros that can be defined in multiple places). This does kind of raise the question as to why delay.h later has this test:

#if __HAS_DELAY_CYCLES && defined(__OPTIMIZE__)
        extern void __builtin_avr_delay_cycles(unsigned long);
        __builtin_avr_delay_cycles(__tmp);
#else
...

I can understand the test for __OPTIMIZE__ but why's it bothering to test __HAS_DELAY_CYCLES when it's #defined at the top of the very same .h file? Just trying to be deliberately confusing for a bear of very little brain like me?

IMHO, the #define in is backwards.
Given that older compilers don't have the builtin delay_cycles() functions, it would seem more logical and backward compatible to have it this way:

#ifndef __HAS_DELAY_CYCLES
#define __HAS_DELAY_CYCLES 0
#endif

That way it is backward compatible with the older compilers, the user can still override it manually, *and* builtins.h can still set it appropriately.

I'll add this additional comment to the Savannah bug report - Which, so far, seems to be ignored.

--- bill

Pages