AVR GCC dont run on VISTA

Go To Last Post
111 posts / 0 new

Pages

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

I know...vista...vista...

its still a pretty nice OS
and after its shoved down our throats by MS...
so i figured ill start learning it now

im impressed on how much stuf works...
course 2 things dont (avrstudio)

Im running with UAC off

the GCC compiler, I get this error

Compiling...
main.c
avr-gcc: _spawnvp: error: No such file or directory

anyone know what that means

i guess avr-gcc is a MFC based code
and that is spawn of some process

prob some path issue...

how would i bring this up with the authors?

thanks all
-Mitch

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

> i guess avr-gcc is a MFC based code

Of course not. ;-)

> and that is spawn of some process

But yes, that's what it does. avr-gcc.exe is just the
compiler driver, and it wants to invoke cc1, [avr-]as,
and [avr-]ld.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

ok its a DEV C++ app then...???

anyway.. any thoughts why its not spawning the cc1 process?

mitch

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

> ok its a DEV C++ app then...?

It's a plain command-line command.

> any thoughts why its not spawning the cc1 process?

No, you probably need to analyze that using a syscall
tracer. Are you sure it's installed correctly? I'd
read the "No such file or directory" error message as
if one of the child programs could not be found in the
expected locations. But of course, it could be that the
error message is just nonsensical.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

A wild guess:

In vista, the filesystem is by default in fsckup-mode. If you are used to XP, and install winavr, winavr won't get installed where you think it'll be installed, and the searchpath won't be set correctly. Instead of putting it in c:\winavr or in c:\program files\winavr, it will be put in an 'emulation folder' in your profile. This enables users to install/modify programs without changing things for other users. When you try to look at the filesystem you will see it as if the files are where they are supposed to be. If this emulation was done thoroughly it wouldn't be a problem, but it's only three-quarterway, and when the spawned process attempts to spawn another, information is lost somewhere.

Copy the winavr installer executable to your desktop, rightclick it, select run as administrator. You may think you are logged in as administrator, but you don't have the admin rights enabled UNLESS you do this. Wait for it to install.
Try if it works now. If not:
Create a shortcut to cmd.exe on your desktop, rightclick and run as administrator, and THEN you can likely invoke the compiler. You probably +edit: need to reboot+ after you install winavr.

Last Edited: Sun. Dec 3, 2006 - 10:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

its for sure a PATH problem...

how does avr-gcc.exe know where the cc1.exe file is
and for that matter when all the standard includes are

having a path of "c\:avrgcc\bin"
it seems to work upwards and back in to other dirs to find files in XP

does not work in vista

mitch

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

I'm just trying to get this to work too.

It's a pain, whatever it is.

ou first get the cc1 / ld not found problem. If you add c:\winavr\avr\bin to the path it then complains about not finding ldscripts. Most odd.

Running the installer as Administrator didn't help for me. It does look like cygwin is not seeing paths correctly.

Does anyone know how that environment normally works? I.e. how does gcc-avr know where ld is?

edit: running cmd as admin doesn't help either.

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

I've worked around it, not ideally, but in a hack it to make it work manner.

Using Process Monitor tool I can see which search paths are being explored and it's not looking in the right places. No idea why, no time to work out why.

This is what I believe I did to get it working for me:

From the directory above your makefile (build directory?) create a Vista symbolic link:

mklink /d avr \winavr\avr

From the directory with your makefile:

mklink /d ldscripts \winavr\avr\lib\ldscripts

Then copy files from:

c:\winavr\lib\gcc\avr\3.4.3\include to
c:\winavr\avr\include

Copy files from:

C:\WinAVR\lib\gcc\avr\3.4.3\avr5 to
c:\winavr\avr\lib\avr5

I'm using Atmel128 so I guess things might be different for others.

This very crude hack - obviously is not a fix. More a "I need this working now and can't be bothered to find a real fix" workaround.

RW.

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

Well.. i dont exactly follow your quick work around...

where is avr-gcc.exe looking for cc1.exe and others...

mitch

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

Oh yes, my path has this in it too. Sorry, missed that.

c:\winavr\libexec\gcc\avr\3.4.3;c:\winavr\avr\bin;C:\WinAVR\bin;C:\WinAVR\utils\bin;

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

realwarder wrote:
[...]
I'm using Atmel128 so I guess things might be different for others.

If you´ve got the toolchain working, it shouldn´t make any difference which of the AVRs you use. The controller type is defined in the makefile, after all.

realwarder wrote:
This very crude hack - obviously is not a fix. More a "I need this working now and can't be bothered to find a real fix" workaround.

Not poking fun at you, but why don´t you then use something that works? Like Win XP or Win 2K?

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

ikletti wrote:

Not poking fun at you, but why don´t you then use something that works? Like Win XP or Win 2K?

Yes, well. Sometimes you have to test your products on the latest OS before others find it doesn't work.

There's a certain irony there...

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

realwarder wrote:
Yes, well. Sometimes you have to test your products on the latest OS before others find it doesn't work.
I fully agree with that.

I also don´t want to go into a lengthy discussion, but I thought you were trying to get avr-gcc and the toolchain working and not one of your products.

Ingo.

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

You just have to activate the index-service of Windwos Vista to get the AVR GCC working correctly.
(In my german vista it is called "Indexdienst", dont know the exact name of the english Windows Vista).

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

Solution: Ignore the existence of Vista...

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

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

Thanks for trying it out on Vista. I'm sorry I can't help as I don't have Vista.

FYI, AVR GCC in WinAVR is built using MinGW/MSYS, so it's nothing to do with any MS-based products.

I would be intersted to know exactly what directories avr-gcc is trying to search.

Eric

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

All workarounds here does'nt work with my Vista. Have anybody another solution?
Does anybody know whether the programmers of WinAVR work on a solution about this problem?

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

WinAVR has noone like a "programmer". It has almost close to one
person who's just assembling that binary distribution, using open
source software from everywhere, and compiling and bundling it for an
easy Win32 installation. I wouldn't call that a programmer (within
that context), as he mostly doesn't touch the existing opensource
software.

So as you guys run into problems with GCC, you'd have to ask the GCC
developers for whether they are working on a solution on this. What
might really help you here is that this is most likely not only tied
to the AVR platform (which is of really minor importance to the GCC
folks) but probably to all Win32 (or Win64?) ports of GCC in general.
On the other hand, about the only purpose of Windows Vista (from what
I can read about it) appears to be the Microsoft platform to enforce
what they call "Digital Rights Management" (and what in fact appears
to be rather a money-printing guarantee for Microsoft and Holywood).
If you consider that the Free Software Foundation (who's the legal
owner of GCC) calls that "Digital Restrictions Management" because
it's the fundamentally opposite of their view of what your rights for
computer data and software should be, this might in fact drastically
lower the priority of a Windows Vista porting effort for GCC.

Just MHO, of course.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

I agree with Joerg on everything he said. My only addition is that I might suggest that you contact the MinGW project on SourceForge and ask them about their support for Vista. The MinGW project puts together a GCC toolchain for Windows hosts. This is what I use to build the core AVR cross toolchain for binutils, gcc and avr-libc.

Eric

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

Hi Mitch,
Hi Guys,

I've successfuly installed and compiled one project on MS Vista Enterprise with WinAVR20070122. You should create the following batch with PATH extensions to start the compiler modules:

@echo off 
setlocal
set AVR=%ProgramFiles%\Atmel\WinAVR
set PATH=%AVR%\libexec\gcc\avr\4.1.1;%AVR%\bin;%AVR%\avr\bin;%AVR%\utils\bin;%PATH%;
set AVRALEXLIB=%CD%\..\lib
set AVRALEXCOMMON=%CD%\..\common
set AVRHEXDIR=%CD%\..\_hex
set DIRAVR=%AVR%
set DIRAVRBIN=%AVR%\bin
set TMP=%CD%\..\_temp
set TEMP=%CD%\..\_temp
echo ...
echo Running in %CD%
echo     Entering now in a new Shell!
echo     Type exit to escape from local!
cmd
endlocal

There my be also inlcude definition problems, if any
please post your help request here!

please test
cheers
Alex

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

Hello Alex,

thank you for your batch. I will test it in the next days and hope it will work also with my system!

Here ist the URL of two commands to this topic I found at the Internet:

http://aarongiles.com/?p=199

http://sourceforge.net/tracker/i...

regards
Harry

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

Hi Harry,

Yes indeed the linx are describing this problem.
The Vista RTM is quite different as it was in Win2k
and WinXP. Because the MS guys extended the security issue for any forked or spawned process. I'll inspect this and report it in a separate topic (not here!)

enjoy
Alex
[/b]

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

I ended up making a virtual pc (xp) do to my avr stuff..
im on vacation, but when i get back ill try the batch
im not sure where to execute it from

mitch

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

skipper wrote:
Hi Mitch,
Hi Guys,

I've successfuly installed and compiled one project on MS Vista Enterprise with WinAVR20070122. You should create the following batch with PATH extensions to start the compiler modules:

@echo off 
setlocal
set AVR=%ProgramFiles%\Atmel\WinAVR
set PATH=%AVR%\libexec\gcc\avr\4.1.1;%AVR%\bin;%AVR%\avr\bin;%AVR%\utils\bin;%PATH%;
set AVRALEXLIB=%CD%\..\lib
set AVRALEXCOMMON=%CD%\..\common
set AVRHEXDIR=%CD%\..\_hex
set DIRAVR=%AVR%
set DIRAVRBIN=%AVR%\bin
set TMP=%CD%\..\_temp
set TEMP=%CD%\..\_temp
echo ...
echo Running in %CD%
echo     Entering now in a new Shell!
echo     Type exit to escape from local!
cmd
endlocal

There my be also inlcude definition problems, if any
please post your help request here!

please test
cheers
Alex

Hi Alex,
thanks for your help. I started your batch file and
make.exe starts compiling now.
The problem are still the include paths.

Do you have an idea how to fix it?
thanks!

Compiling C: main.c
avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -
funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wunde
f -Wa,-adhlns=obj/main.lst  -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c
-o obj/main.o
main.c:1:19: error: stdio.h: No such file or directory
In file included from main.c:2:
main.h:1:20: error: stdint.h: No such file or directory
main.h:6:20: error: avr/io.h: No such file or directory
main.h:7:27: error: avr/interrupt.h: No such file or directory
main.h:8:24: error: util/delay.h: No such file or directory
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

please upload your makefile!

I'll check or fix it as soon as possible!

Cheers
Alex

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

I think this solves the include problems:

set C_INCLUDE_PATH=%AVR%\avr\include
set LIBRARY_PATH=%AVR%\avr\lib
set GCC_EXEC_PREFIX=%AVR%\
set LD_LIBRARY_PATH=%AVR%\lib

I'm not sure if they all do something but it has worked. However now I get another error:

ld: cannot open linker script file ldscripts/avr5.x: No such file or directory

Also, when it did compile (I don't know what has changed in since then) avr-objcopy complained about sections eeprom that could not be copied. This could be because this section is not present and the application fails:

c:\Program Files\WinAVR\bin\avr-objcopy.exe: there are no sections to be copied!

I'm trying to make a small AVR Studio launcher application that sets up the right environment for AVR studio in Vista.

EDIT

Both problems were solved with the beta version of AVR Studio 4.13. This is also the only version that works with the latest WinAVR.

I have made a small launcher tool for AVR studio.
StudioLauncher.zip
Place the exe inside somewhere on your PC and make a shortcut to it. Use this shortcut to start AVR studio and hopefully it works. I did get some heap errors sometimes but they seem to be incidental.

Make sure you have the latest WinAVR installed and the
AVR studio beta!

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

hi every body
my WinAVR20070122 does not work on vista
i have installed it on c:\program files\winavr
and used the last batch file above
it says
> "make.exe" all
avr-gcc -g -Wall -O2 -mmcu=atmega8 -c -o demo.o demo.c
avr-gcc: _spawnvp: No such file or directory
make.exe: *** [demo.o] Error 1

> Process Exit Code: 2

if some body knows the problem please help me
and send me an email
my email is "ali_dehbidi@yahoo.com"
thanks for your concern

I love Digital
and you who involved in it!

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

madwizard wrote:
I think this solves the include problems:

set C_INCLUDE_PATH=%AVR%\avr\include
set LIBRARY_PATH=%AVR%\avr\lib
set GCC_EXEC_PREFIX=%AVR%\
set LD_LIBRARY_PATH=%AVR%\lib

I'm not sure if they all do something but it has worked. However now I get another error:

ld: cannot open linker script file ldscripts/avr5.x: No such file or directory

...
Running in D:\Atmega32
    Entering now in a new Shell!
    Type exit to escape from local!
Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation. Alle Rechte vorbehalten.

D:\Atmega32>make all
bash.exe: warning: could not find /tmp, please create!
bash.exe: warning: could not find /tmp, please create!

-------- begin --------
avr-gcc (GCC) 4.1.1 (WinAVR 20070122)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

bash.exe: warning: could not find /tmp, please create!

Size before:
main.elf  :
section            size      addr
.text              4080         0
.data               470   8388704
.bss                 14   8389174
.stab               876         0
.stabstr            132         0
.debug_aranges       32         0
.debug_pubnames     378         0
.debug_info        3503         0
.debug_abbrev       768         0
.debug_line        3102         0
.debug_frame        368         0
.debug_str          696         0
.debug_loc         2265         0
Total             16684




Compiling C: main.c
avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -
funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wunde
f -Wa,-adhlns=obj/main.lst  -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c
-o obj/main.o
main.c: In function 'main':
main.c:43: warning: unused variable 'p'

Linking: main.elf
avr-gcc -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -fun
signed-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -
Wa,-adhlns=obj/main.o  -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o
 --output main.elf -Wl,-Map=main.map,--cref    -lm

Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex

Creating load file for EEPROM: main.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex main.elf main.eep
bash.exe: warning: could not find /tmp, please create!
/usr/bin/sh: /d/Daten/WinAVR/bin/avr-objcopy: Invalid argument
make: [main.eep] Error 126 (ignored)

Creating Extended Listing: main.lss
avr-objdump -h -S main.elf > main.lss
bash.exe: warning: could not find /tmp, please create!
/usr/bin/sh: /d/Daten/WinAVR/bin/avr-objdump: Invalid argument
make: *** [main.lss] Error 126

Ok thanks!
The new problem is the /tmp directory. Where must I create it??

bash.exe: warning: could not find /tmp, please create!

Second Problem, the EEPROM File will not be created!

I use Win AVR from 22.01.2007.
I would be very useful, if somebody could create a intruction how to fix the problems.
thanks!

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

/tmp should work fine if your TEMP and TMP variables are set to a valid directory. This should be done by windows anyway. The batch files earlier in this post do this:

set TMP=%CD%\..\_temp
set TEMP=%CD%\..\_temp 

These overrule the defaults from Windows to a directory that probably does not exist on your machine. Just remove those lines and it should work fine, or create the ..\_temp directory.

If you get heap errors (this happens often but not always) this can be fixed by rebasing msys-1.0.dll as mentioned in another thread. Here is a new version of the DLL, put it in {Winavr}\utils\bin over the old one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
ld: cannot open linker script file ldscripts/avr5.x: No such file or directory[

Following your steps I am getting these errors.how do I get around this error?

also studio launcher is not working for me

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

I had that problem only with existing projects. Try creating a new project and put your old source files in it, it probably works then.

The msys DLL that was rebased does not work all the time btw, I still had lots of heap errors. I think I have fixed it with a small patch but I'll do some more tests. There's some really ugly programming in msys.

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

I have looked into it once more and think I have found the root of the problem. It seems WinAVR passes an invalid parameter to the _access C function that checks whether a file or directory exists or which rights it has. WinAVR searches several paths for its subprograms (cc1.exe), including correct ones but because of the invalid parameter and the lack of error checking it falsely assumes the correct path does not exist.

This problem is new in Vista because it uses a newer version of msvcrt.dll . Older versions did not check (completely) for invalid parameters. It is still a bug in WinAVR though, under BSD/Linux the _access function differs slightly from Windows. There it checks for the 'execute' right, which does not exist as such in windows. Windows can still check if the file exists though, it justs needs a different parameter.
I've posted full details in the WinAVR bug report.

It should be quite easy to fix in the source code but as I'm not familiar with the build environment WinAVR is built in I'll leave this to someone else.

Still, I did make a binary patch for avr-gcc.exe. It is explained in the bug report but I've made a downloadable fixed version as well:
avr-gcc-bugfix.zip
Put this avr-gcc.exe over the old one in bin\, be sure to make a backup first in case it does not work.

You do not need the batch file nor the launcher anymore with this fix.

Only use this patch with latest WinAVR (20070122).
Let me know if you have any other executables that give errors.

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

YOU ARE THE MAN!

THANK YOU, THANK YOU

my code now compiles 100% in vista with the
new avr-gcc.exe

-Mitch
:lol:

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

I WAS ON TO THIS A MONTHS AGO!
ARG!!!!

read my post

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=40402

my last couple posts

why i didnt remember this i dont know
i guess i fell in love with VirtualPC and kept
going to XP from vista to do my atmel work

sorry!

mitch

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

mitchjs: Too bad I missed that post of yours :) I have reported the fix to a WinAVR bug report and posted a bug report on the GCC bugzilla. Both haven't had any responses yet but at least the binary patch works. I'm not that familar with the whole cygwin/mingw/msys (whatever winavr is compiled with) system so fixing the binary is a lot easier for me than to fix the source.

To elaborate a bit more on the patch, like mitchjs found _access is called with the wrong parameter. Basically GCC needs to find its cc1.exe subprogram. To do this it guesses a couple of paths and uses stat and _access to see if it has found a valid one. Normally it finds a valid path and uses it but on Vista (and some win98 versions as well it seems) it fails. The _access function takes a filename/path and a mode to check for (existance, read access, write access etc.). On unix/linux/etc. one can use mode 1, which checks for execute rights (basically this checks for existance). In windows, there is no such mode. To be more specific, msvcrt's _access function does not allow it, see the documentation. mitchjs has also mentioned this in his post.

So GCC has been wrong all along (well, it is right on other systems but not on windows), we just didn't notice it because older versions of msvcrt.dll does not check its mode parameter for proper values. Later versions of msvcrt.dll do, this is why gcc differs on Vista. GCC does not check the error value of _access, but falsely assumes that the path to cc1.exe it tried to access does not exist. At the end it gives up and just spawns "cc1.exe", without any path. This is the spawnvp error everyone gets, it tries to spawn cc1.exe but because it couldn't find the absolute path this fails if cc1.exe is not in your path. This is also why all the PATH settings in the batch files sort of fix the problem.

The patch works as follows: Luckily avr-gcc was compiled with a sloppy linker that left the DLL's import library stubs.
The fix is here

.00417690: FF25DC214200                 jmp       [0004221DC]; _access ;msvcrt.dll
.00417696: 90                           nop
.00417697: 90                           nop
.00417698: 0000                         add       [eax],al
.0041769A: 0000                         add       [eax],al
.0041769C: 0000                         add       [eax],al
.0041769E: 0000                         add       [eax],al
.004176A0: FF25F4214200                 jmp       _putenv ;msvcrt.dll

The top address is the jump to msvcrt's access, this address is called whenever the function needs to be called. The nop's and 00's are just padding to the next function stub (which happens to be putenv). The patch changes it into:

.00417690: 90                           nop
.00417691: A1DC214200                   mov       eax,[0004221DC] ; _access address
.00417696: 81642408FE000000             and       d,[esp][00008],0000000FE ;"
.0041769E: FFE0                         jmp       eax
.004176A0: FF25F4214200                 jmp       _putenv ;msvcrt.dll

The address is put into eax, the mode parameter [esp+8] is ANDed with 0xFE so that mode 1 becomes mode 0, and then calls _access through eax.

mithcjs PM'd me on the fact that my patch seems a little odd (your address differs btw, older version?) and wrote:

Code:

004176B0   $  816424 08 FE000000       AND DWORD PTR SS:[ESP+8],0FE
004176B8   .- FF25 DC214200            JMP DWORD PTR DS:[<&msvcrt._access>]                   ;  msvcrt._access


is good enough, the its just the reference to the inport table, not the inport table itself 

This is true but I wrote it in such a way for a reason. My patch leaves the indirect address of _access at the same spot in memory. When the executable would be relocated, windows changes these addresses and if it is at the same spot the address would change correctly. If it has moved in location the wrong bytes will be relocated.
However, I forgot for a minute that executables, unlike DLLs, rarely have relocation information. In fact, avr-gcc doesn't have any so your patch would work just as well (apart from that you seem to have a different version). You could also use 'and byte ptr [esp+8], 0xFE if you really want to save space :).

Anyway I hope this gets fixed properly in the source time but I guess this will take some time. There may be other programs in the WinAVR package that also suffer from this problem, they can likely be fixed in the same way.

Also, if you have any cygwin heap errors it is likely msys-1.0.dll to be the problem. Relocating the DLL works, but the suggested 0x70000000 address still causes problems often. I found a better address to be much lower, such as 0x30000000. I'll put up a new rebased version of it.

The cygwin heap problem is inherent to the way cygwin's memory management works. It needs to allocate memory for different processes at exactly the same spot in memory. In unix like systems the fork system call does this and there never is a problem. Windows does not have such a thing (luckily) but this does still mean that the heap needs to be cloned at the same address for cygwin programs so that all the pointers will still be valid. If there's any DLL that happens to be loaded by the new process first which overlaps with the memory cygwin's heap should be, cygwin can't allocate this heap. There's no real solution for this problem other then rewriting the whole system so all you can do is reduce the chance that cygwin's heap and DLLs collide in memory. Rebasing the DLL to a lower address does this quite effectively though it will never be fool proof.

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

I have placed everything on a small webpage so that it will be easier to find for those that do not visit this forum: Using WinAVR in Windows Vista

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

very good...

would have done the byte wise and
but i was ok with the word...

I think windows would not change that memory addres (ever), but the address in the table that its pointed to

the RVA address will always be $4221dc for that call
the address at 4221dc will change when loaded to point to the import of the mscvrt.dll

if my windows PE file format (limited) skills are working :)

anyway... thats not the point.. the point is
you got it... and me happy, and im sure others too!

im sure GCC for windows has many other minor issues
prob needs a windows guy to clean up :)

cygwin's heap errors arnt poping up on my system
vista with 2gb

mitch

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

mitchjs wrote:
very good...
I think windows would not change that memory addres (ever), but the address in the table that its pointed to

the RVA address will always be $4221dc for that call
the address at 4221dc will change when loaded to point to the import of the mscvrt.dll


There are two levels here, first of all you have the address of _access itself, which can change quite easily because of relocations. This address is stored normally at 4221DC. The jump to _access (or a call if the linker would remove the stubs) is:

jmp dword ptr [4221DC]

This is an absolute address, 4221DC is stored directly in memory, not relative to the instruction pointer. You can see this in the opcode (in little endian so reversed):

FF 25 >DC 21 42 00<       jmp       [0004221DC];

Suppose the executable *would* be relocated. The default base for executables is 400000, but if windows relocates it to say 600000, the address of _access would then be stored at 6221DC. Still, because the 4221DC address is absolute and hardcoded in the opcode, the jump would go to [4221DC], while the real address is at [6221DC]. It would crash, likely with an access violation.

If this bug were in a DLL instead of an EXE you would have to deal with it, since the base address could easily change. In a DLL, the relocation table would have an entry for the 'DC 21 42 00' DWORD in the opcode, stating that these bytes represent an address and they should be relocated if the DLL changes its base.

So it is a valid problem, just not for executables since they don't have relocation information.

Quote:
cygwin's heap errors arnt poping up on my system vista with 2gb

Same here, Vista with 2GB. But with the default msys I get them all the time. Base 0x70000000 works a bit better but still often an error. Strangely it happens more often when I hit the 1GB memory usage.

I've included the new DLL anyway to prevent any problems.

edit:
Small example of the problem, take the kernel Sleep call in the default msys-1.0 DLL, which does have relocation information.

.710A15D8: FF25ACF50F71                 jmp       d,[0710FF5AC] ; Sleep
.710A15DE: 90                           nop
.710A15DF: 90                           nop
.710A15E0: FF25B8F40F71                 jmp       d,[0710FF4B8] ; LoadLibraryA

The default base is 71000000. A Sleep call and LoadLibraryA. If you relocate this with the rebase tool to 30000000, you get:

.300A15D8: FF25ACF50F30                 jmp       d,[0300FF5AC] ; Sleep
.300A15DE: 90                           nop
.300A15DF: 90                           nop
.300A15E0: FF25B8F40F30                 jmp       d,[0300FF4B8] ; LoadLibraryA

As you can see, the address is corrected as well. Now what if we add a nop to the original sleep call:

.710A15D8: 90                           nop
.710A15D9: FF25ACF50F71                 jmp       d,[0710FF5AC] ; Sleep 
.710A15DF: 90                           nop
.710A15E0: FF25B8F40F71                 jmp       d,[0710FF4B8] ; LoadLibraryA

The position of the address has changed. If you relocate this:

.300A15D8: 90                           nop
.300A15D9: FF25ACF5CE71                 jmp       d,[071CEF5AC] ; ????????
.300A15DF: 90                           nop
.300A15E0: FF25B8F40F30                 jmp       d,[0300FF4B8] ; LoadLibraryA 

The address is corrupted. If you look closely at the bytes:

Original:  90 FF 25 AC F5 0F 71
Relocated: 90 FF 25 AC F5 CE 71

You see that 0F has changed to CE. Relocation from 71000000 to 30000000 is -41000000.
0F - 41 = CE. It changed the wrong byte. It should have changed 71: 71 - 41 = 30. But the relocation information still points to the same address, before the NOP was inserted.

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

right in the dll, one could edit relocation table :)
anyway ur fix is safe

other fix, it to go back to the code and fix all the call from pushing wrong prams on stack
since thats what one would do if u recompiled the source

anyway.. we're way off topic, thats why i PMed it in the first place, thanks for the education

now back to msys-1.0 DLL

i downloaded yours and compaired it to my existing
its the same...

mine is from GCC4.1.1

-Mitch

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

mitchjs wrote:
right in the dll, one could edit relocation table :)
now back to msys-1.0 DLL

i downloaded yours and compaired it to my existing
its the same...

mine is from GCC4.1.1


You mean it's *exactly* the same, or just apart from the rebase? The one online is rebased to 0x30000000, I just checked.

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

doh, i must have replaced it, when u posted it a few days ago..

yes its imagebase is at 0x3... vs 0x71

not that i have seen any issues yet with it at x71
keep up the good work :)

Mitch
mitch

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

@madwizard:

Thank you very much! Now all my problems are blown away and I do not have WinXP installed for compiling any longer!

Michael

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

Unfortunately the patch doesn't work with my Windows Vista 64-Bit. The compiler runs, but after the linking-process it breaks off with an unknown error 128.

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

hhehe
at 64 bit OS running a 32 bit program to code a 8 bit program...

64bit vista the ultimate incompatablity!
i was risking 32bit vista, for someone to jump to 64bit... takes guts

did the compiler work on 64 bit XP?

mitch

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

hi,

I have been trying to get avr to run on vista. I have followed all the steps as stated earlier by madwizard.
My project begins to compile without the spanwp error. However the avr program closes abruptly , giving me an "MFC error caused the program to stop working".

The default location where my winavr has been installed is not in the program files folder. Could this be the problem ?

I would highly appreciate your assistance

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

MFC errors can't be from winavr, they are from AVR Studio. Do you have the latest version? Also try creating a new project and import your source file in the new project.

@marsbotschafter: I've got an e-mail from someone about 64-bit problems as well, he gets fork errors ("child died before initialization"). but since I don't have any 64-bit installations here its very hard to test for me. I just can't reproduce it.

Could you be more specific about the errors you get? What is the exact output? Try narrowing it down, try it without a makefile, pin down the exact program that fails, etc.

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

Has anyone found a solution to the MFC error yet?

Thank you!

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

INSTALL THE NEW AVRSTUDIO!

http://www.atmel.no/beta_ware/

the compiler isnt written in MFC

-Mitch

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

Still happens to me with v4.13 build 528 on Vista RTM.

AVR Studio loads OK. To cause the crash:
- Create a new project of type "AVR GCC"
- pick "AVR Simulator" or "AVR Simulator v2" (targeting ATMEGA128)
- In the c window type "main() { }"
- Build the project

After the build process has finished up pops:

"AVRStudio MFC Application has stopped working" and you have to close it down.

At this point re-launching AVRStudio and even just re-opening the project file will cause an immediate crash.

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

Just a quick thought - everyone was so quick to blame Vista for the avr-gcc _spawnvp error. If you've read the thread you see that the problem was always in WinAvr - just that Vista picked up on a bug that's always been there by validating paramters better.

This is the sort of behaviour that I would expect and encourage in a revamped OS, and if it breaks a few badly-written apps then so be it.

Vista is a fine OS in my experience, and is definitely getting a bad rap from those with an alternative agenda to push.

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

mikealex wrote:
Still happens to me with v4.13 build 528 on Vista RTM.
[...]

This doesn't reproduce the error on my PC...

mikealex wrote:
Just a quick thought - everyone was so quick to blame Vista for the avr-gcc _spawnvp error. If you've read the thread you see that the problem was always in WinAvr - just that Vista picked up on a bug that's always been there by validating paramters better.

Good point, WinAVR has been working in the past just by coincidence. Vista only brought this to light, and the winavr bug list also shows the same problem in win98 with some msvcrt version.
edit: to be correct, the bug is in GCC, WinAVR is just a set of existing tools. The bug is in the source code of GCC and I've seen similar bug reports in the ARM version of GCC.

I've found some earlier references to the access bug as well (of course you always find these things just after you've figured it out yourself) but it does not seem like anyone has ever done anything about it, or is going to.

These linux/unix/.. ports of programs are always tricky, windows is quite a different platform and although there are frameworks like cygwin an msys they are not perfect and use some dirty tricks. Especially forking of processes (which has always seemed a weird way to create a process to me anyway) is completely incompatible with the windows API. That is probably why 64-bits Vista still has problems with it.

Pages