| Author |
Message |
|
|
 Posted: Jan 31, 2007 - 06:42 AM |
|
Joined: Jan 29, 2007
Posts: 4
Location: Traunreut
|
|
|
|
|
|
|
|
Posted: Jan 31, 2007 - 08:56 AM |
|
Joined: Jan 02, 2003
Posts: 28
|
|
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] |
|
|
| |
|
|
|
|
|
|
Posted: Feb 01, 2007 - 03:45 PM |
|
Joined: Jun 24, 2004
Posts: 97
Location: Philadelphia, PA
|
|
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 |
|
|
| |
|
|
|
|
|
|
Posted: Feb 11, 2007 - 02:28 PM |
|
Joined: Jul 01, 2006
Posts: 2
|
|
|
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:
Code:
@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!
Code:
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
|
|
|
| |
|
|
|
|
|
|
Posted: Feb 15, 2007 - 09:12 PM |
|
Joined: Jan 02, 2003
Posts: 28
|
|
please upload your makefile!
I'll check or fix it as soon as possible!
Cheers
Alex |
|
|
| |
|
|
|
|
|
|
Posted: Feb 17, 2007 - 09:22 PM |
|
Joined: Apr 27, 2005
Posts: 73
Location: Netherlands
|
|
I think this solves the include problems:
Code:
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:
Code:
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:
Code:
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! |
|
|
| |
|
|
|
|
|
|
Posted: Feb 21, 2007 - 06:28 AM |
|
Joined: Dec 22, 2005
Posts: 1275
Location: shiraz , iran
|
|
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 |
|
|
| |
|
|
|
|
|
|
Posted: Feb 21, 2007 - 12:01 PM |
|
Joined: Jul 01, 2006
Posts: 2
|
|
|
madwizard wrote:
I think this solves the include problems:
Code:
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:
Code:
ld: cannot open linker script file ldscripts/avr5.x: No such file or directory
Code:
...
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! |
|
|
| |
|
|
|
|
|
|
Posted: Feb 21, 2007 - 12:41 PM |
|
Joined: Apr 27, 2005
Posts: 73
Location: Netherlands
|
|
/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:
Code:
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. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 23, 2007 - 07:18 AM |
|
Joined: Feb 23, 2007
Posts: 1
|
|
|
Code:
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 |
|
|
| |
|
|
|
|
|
|
Posted: Feb 24, 2007 - 12:29 PM |
|
Joined: Apr 27, 2005
Posts: 73
Location: Netherlands
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 26, 2007 - 12:49 PM |
|
Joined: Apr 27, 2005
Posts: 73
Location: Netherlands
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 27, 2007 - 04:45 PM |
|
Joined: Jun 24, 2004
Posts: 97
Location: Philadelphia, PA
|
|
YOU ARE THE MAN!
THANK YOU, THANK YOU
my code now compiles 100% in vista with the
new avr-gcc.exe
-Mitch
 |
|
|
| |
|
|
|
|
|
|
Posted: Feb 27, 2007 - 04:55 PM |
|
Joined: Jun 24, 2004
Posts: 97
Location: Philadelphia, PA
|
|
|
|
|
|
|
|
Posted: Feb 27, 2007 - 08:19 PM |
|
Joined: Apr 27, 2005
Posts: 73
Location: Netherlands
|
|
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
Code:
.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:
Code:
.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:
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. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 27, 2007 - 10:08 PM |
|
Joined: Apr 27, 2005
Posts: 73
Location: Netherlands
|
|
| 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 |
|
|
| |
|
|
|
|
|
|
Posted: Feb 27, 2007 - 11:15 PM |
|
Joined: Jun 24, 2004
Posts: 97
Location: Philadelphia, PA
|
|
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 |
|
|
| |
|
|
|
|
|
|
Posted: Feb 28, 2007 - 12:40 AM |
|
Joined: Apr 27, 2005
Posts: 73
Location: Netherlands
|
|
|
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:
Code:
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):
Code:
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.
Code:
.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:
Code:
.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:
Code:
.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:
Code:
.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:
Code:
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. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 28, 2007 - 01:43 AM |
|
Joined: Jun 24, 2004
Posts: 97
Location: Philadelphia, PA
|
|
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 |
|
|
| |
|
|
|
|
|
|
Posted: Feb 28, 2007 - 10:10 AM |
|
Joined: Apr 27, 2005
Posts: 73
Location: Netherlands
|
|
|
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. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
