In C there is no main program. Sure, C programmers begin with int main(int argc char *argv[]), but this only works because there is a routine that tells the compiler/IDE to run the function named main first.
I can't seem to find this routine in MinGW, though. Where is it defined? I just searched because I wanted to change it (only as a test) and play around with it a bit. Can someone link me to the correct file in the MinGW folders?
The ld linker will look for a match of one of several symbols to use as the entry point when linking a PE file:
entry point subsystem
--------------------- --------------
NtProcessStartup native
WinMainCRTStartup Windows GUI
mainCRTStartup Windows CUI (console)
__PosixProcessStartup POSIX CUI
WinMainCRTStartup WinCE GUI
mainCRTStartup Xbox
mainCRTStartup other
DllMainCRTStartup#12 (or possibly DllMainCRTStartup) for DLLs
MinGW will have an object file that gets automatically linked in that has the actual PE entry point. - you can see what object files are being automatically linked in by using gcc's -v option.
In a quick test using MinGW 4.6.1 building a console subsystem "hello world" program, the object file containing the entry point is crt2.o and it has a symbol mainCRTStartup that is picked up by the linker as the entry point.
The source file containing the entrypoint code is crtexe.c (or crtdll.c).
You can override the entry point using the --entry option to the linker (Wl,--entry=whatever when used on the gcc command line).
Related
I'm trying to open a simple file open dialog in Tcl/Tk but whenever I run tk_getOpenFile I get the following error:
invalid command name "::tk::dialog::file::"
while executing
"::tk::dialog::file:: open {*}$args"
(procedure "tk_getOpenFile" line 5)
invoked from within
"tk_getOpenFile"
(procedure "open" line 2)
invoked from within
...
I'm running the latest version of Tcl/Tk, 8.6.9, from the Arch Linux repositories. What could be causing this?
It looks like a broken installation somehow. The procedure tk_getOpenFile in …/tk.tcl (where … is where Tk's library files are installed) delegates to the procedure ::tk::dialog::file:: in …/tkfbox.tcl (yes, an unusual procedure name), but that doesn't seem to be working in your case. Either the file is missing, or the tclIndex file in the same directory is broken. (That's using an old mechanism for auto-loading of code that doesn't really make sense for new code to use in… well, in this millennium. It's kept for backward compatibility.)
I have compiled a simple binary file (hello.bin) and stored it on a memory card.
I am running a NXP Sabre dev kit with i.mx 6 quad processor. I have started up U-boot and am trying to access the binary file and make it run.
The hello.bin is availiable because the following command works:
=> fatload mmc 1:4 0x20005000 hello.bin
reading hello.bin
The way I understand it the file should be loaded into RAM at the address 0x20005000
So I want to test that the binary is there
=> md 0x20005000
20005000: 464c457f 00010101 00000000 00000000 .ELF............
20005010: 00280002 00000001 00010315 00000034 ..(.........4...
20005020: 000028f4 05000400 00200034 00280009 .(......4. ...(.
20005030: 00240025 70000001 00000454 00010454 %.$....pT...T...
Looks all right, as the starting bits are matching the file I copied to SD-card.
When I try to start the binary, the device reports undefined instruction:
=> go 0x20005000
## Starting application at 0x20005000 ...
undefined instruction
pc : [<20005158>] lr : [<4ff71403>]
reloc pc : [<e7897158>] lr : [<17803403>]
sp : 4f56dd50 ip : 00000000 fp : 00000002
r10: 4f56f938 r9 : 4f56deb0 r8 : 4ffc3c40
r7 : 4ff713d9 r6 : 00000002 r5 : 20005000 r4 : 4f56f93c
r3 : 20005000 r2 : 4f56f93c r1 : 4f56f93c r0 : 00000000
Flags: nzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
Thanks for your help
Please, find an example at https://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.1.
go does not expect the start of an ELF binary but the address of the entry routine. If you want to access U-Boot routines the binary must have been relocated.
I have compiled a simple binary file (hello.bin) and stored it on a memory card.
You have omitted many salient details.
How did you compile this program, e.g. what toolchain, what makefile?
Did you link this program with a library?
The way I understand it the file should be loaded into RAM at the address 0x20005000
How did you get this "understanding"?
Typically the load address of a standalone program depends on a few factors.
First the addresses of available memory (on the target board) has to be considered.
Second, unless the standalone program is relocatable (not likely in your case), then the program must be loaded at its load/starting address as defined when the program was linked.
The load and starting addresses of a program can be obtained from its map file (i.e. the linker output).
When I try to start the binary, the device reports undefined instruction:
That is what happens when the ELF header is "executed".
Since the file clearly contains an ELF header, its filename extension should be .elf rather than .bin.
How did this executable file get the misleading name?
You probably did not build a standalone binary image file.
The examples/standalone/ directory of the U-Boot source code has sample code and a makefile for building standalone binaries, e.g. a hello_world.bin.
Be sure to properly define CONFIG_STANDALONE_LOAD_ADDR for your board!
The default load address is surely to be inappropriate.
the => bdinfo, command told me something about the DRAM bank, starts at 0x10000000 (7 zeros) and ends at 0x4000000.
(First of all, do not put salient information in comments. Add this to your original post by using the edit capability.)
The "information" you provided makes no sense (i.e. the end address is less than the start address). Avoid interpreting the information, and instead simply present (copy'n'paste) the actual output.
I then used fatload mmc 1:4 0x10005000 hello.bin instead, which then seems to work. I guess I was writing to a out of bound address.
The fatload command merely copies the contents of a file into memory. The true success of that copy is confirmed by validating the memory, rather than completion of the command.
Your comment is confusing since you have not mentioned any prior load issues.
go 0x10005000 still does not work.
Trying arbitrary load/start addresses is not an effective debugging technique.
A summation of "seems to work" or "still does not work" is a low-quality description for results.
See How To Ask Questions The Smart Way.
Got some help from another friend, I found it very helpful so I will post it:
You can use the Yocto toolchain but you cannot link against the C library (which is done by default) so you have to put some extra options to GCC to let it know that, also, you cannot use the go instruction from U-Boot to jump to an ELF binary that you just loaded in memory, the ELF binary has to be converted to a 'raw' binary (list of ARM instructions in your case) with the tool objdump. An ELF binary it's a specific format that encapsulate your code/your data and some extra information, and the first part of the ELF is the description of the binary, so right now, when you do a go at the first address, you are trying to tell the CPU to execute something which is not an ARM instruction. You basically want to execute what we call the '.text' section of the ELF binary.
Apologies for incredible ignorance. First time ever looking at or trying coding in any form and all naturally a bit confusing and overwhelming.
Trying to keep it super basic I'm attempting to build something basic for Amazon Echo by working through this article - https://developer.amazon.com/blogs/post/Tx3DVGG0K0TPUGQ/updated-alexa-skills-kit-fact-template-step-by-step-guide-to-build-a-fact-skill
Have got to Step 2.3
Once you have the source downloaded [done], node installed and npm updated, you are ready to install the ASK-SDK. Install this in the same directory as your src/index.js file for your skill. Change the directory to the src directory of your skill, and then in the command line, type: npm install --save alexa-sdk
I've moved the SDK into the same folder as the source - in downloads folder. Am confused on changing the directory to the same as my skill. As far as I know there is no skill yet so not sure where to move it to.
When type in npm install --save alexa-sdk
returns
npm WARN enoent ENOENT: no such file or directory, open '/Users/OwenLee/package.json'
npm WARN OwenLee No description
npm WARN OwenLee No repository field.
npm WARN OwenLee No README data
npm WARN OwenLee No license field.
working on a mac so don't really know how/where to access this, but assuming this is where i need to move the files to?
Very sorry for baby-basic knowledge. Just trying to at least get a foot in the door as know need to learn this stuff but everything i read seems to assume i already have a working knowledge of coding : S
any help would be awesome - inc. any advice on steps after that you can probably see i'll trip up on
thanks!!
oven121
So as far as the directory /Users/OwenLee/ this would be your home folder on a Mac. The Root / of your HDD can be reached through Finder by clicking on Macintosh HD (or whatever you named your main hard drive) in the side bar. If you open up a new Terminal window it will be the directory that the terminal starts in. You should be able to fix your problem by taking the file packages.json, which should be wherever you downloaded the SDK to, and placing it in your home folder, then re-running the command.
Now don't let me change your mind if you're truly committed, but if you have absolutely no experience with programming I would recommend starting with something a bit simpler than Java or Javascript. Object oriented languages can be both very convoluted and difficult to get the hang of for beginners (I personally have been writing native languages like C for years and am just now starting to understand how Java works.).
If it is an option I recommend starting with a language that your Mac has built in support for. Perhaps start with Bash scripting or Apple Script making basic scripts to do things you find tedious to do manually in a terminal, or get to know the basics of processor-native languages like C & C++ by making some basic programmes to display text when it is run, or to ask the user to type something, and say back what they typed. Finally since you are on a Mac you can get Xcode for free in the app store, it will configure itself and you could play around with it to learn how macOS handles windows, perhaps start by making a basic programme window with a few buttons that do different things when clicked.
If you have any interest in my suggestions you can find some info about bash scripting here: https://linuxconfig.org/bash-scripting-tutorial the tutorial says it assumes the reader has no previous knowledge of Bash, and most commands should work fine in the version of Bash built into your Mac's Terminal app.
If you take more interest in C++ this is the site that I used to learn to write it, and learn how native languages work: http://www.cplusplus.com/doc/tutorial/
Finally here is a basic C++ programme called "Hello World", it is somewhat of an initiation rite of C/C++ students to write this programme and learn how each part of it works:
//HelloWorld.cpp the double slash tells the compiler and user that everything after it on this line is a comment, not code//
#include <iostream> //The octothorp '#' lets the compiler know it needs to use the library named inside the pointed brackets '</>' when it builds the programme. 'iostream' stands for In-Out Stream, and handles basic text, and basic processor commands//
using namespace std; //This line tells the compiler that any line that says to show text or ask the user to type something should use regular text and not a special format//
int main() //'int' stands for integer, any time you make a variable that contains only an integer you should put this in front of it's name, and 'main' is the name of the integer. The empty parentheses tells the compiler that this is a function, rather than a number//
{ //The open curly bracket '{' tells the compiler where the function starts
cout<<"Hello World"; //'cout' stands for 'character out' and is for showing basic text in the terminal window. The double pointy 'out' brackets '<<' tells the compiler that the text should be sent out of the programme rather than loaded into a variable, the text inside the quotes is what will be shown on the screen, and the semi colon tells the compiler where the command ends, it has to be put at the end of any command that is inside of a function//
return 0 //The command 'return' is for telling the compiler whether or not an error has occurred, 0 means the programme ran fine, 1 means something went wrong, either way the programme closes when it runs the command 'return'//
} //the closed curly bracket tells the compiler where the function ends//
Good luck with your programming, and if you have any questions unrelated to this thread please feel free to private message me, or create a new question and tag me in it so that I get notified.
I'm working with GT.M source code and read this information in mumps.hlp file :
ZCOMpile
The ZCOMPILE command invokes the GT.M compiler from within the GT.M
run-time environment.
Within GT.M itself, ZCOMPILE provides the functionality of the
mumps command, except for mumps -direct.
So...which compiler to be using in "mumps -direct" mode , which file store source code for this compiler ?
I mean that ,when you type :
GTM> SET ^FOO="BAR"
Which compiler responsible for compiling that command
Ryo,
It's compiled in memory. It's not stored in any file.
--Sam
I am trying to set up Point Cloud Library trunk build with CUDA options enabled.
I believe I have installed CUDA correctly, following these instructions.
In the cmake options for the PCL build, some options are unrecognised:
Is there something I can manually set CUDA_SDK_ROOT_DIR to? Likewise for the other unfound options.
CUDA_SDK_ROOT_DIR should be set to the direction in which you installed the NVIDIA's GPU Computing SDK. The GPU Computing SDK is downloadable from the same page at NVIDIA where you downloaded CUDA. By default, this SDK will install to $HOME/NVIDIA_GPU_Computing_SDK. Set it appropriately and then rerun cmake.
Edit:
The CUDA_SDK_ROOT_DIR variable is actually looking for the sub-directory beneath $HOME/NVIDIA_GPU_Computing_SDK that contains the version of CUDA you're using. For me, this is $HOME/NVIDIA_GPU_Computing_SDK/CUDA/v4.1.
The source code for FindCUDA.cmake gives some hints on how this path is found:
########################
# Look for the SDK stuff. As of CUDA 3.0 NVSDKCUDA_ROOT has been replaced with
# NVSDKCOMPUTE_ROOT with the old CUDA C contents moved into the C subdirectory
find_path(CUDA_SDK_ROOT_DIR common/inc/cutil.h
"$ENV{NVSDKCOMPUTE_ROOT}/C"
"$ENV{NVSDKCUDA_ROOT}"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\NVIDIA Corporation\\Installed Products\\NVIDIA SDK 10\\Compute;InstallDir]"
"/Developer/GPU\ Computing/C"
)
I.e. check that NVSDKCOMPUTE_ROOT or NVSDKCUDA_ROOT environment variables are set correctly.
On a Linux machine,..
Add "$ENV{HOME}/NVIDIA_GPU_Computing_SDK/C" to the 'find_path' options in FindCUDA.cmake module: (usr/share/cmake-2.8/Modules/FindCUDA.cmake)
########################
# Look for the SDK stuff. As of CUDA 3.0 NVSDKCUDA_ROOT has been replaced with
# NVSDKCOMPUTE_ROOT with the old CUDA C contents moved into the C subdirectory
find_path(CUDA_SDK_ROOT_DIR common/inc/cutil.h
"$ENV{HOME}/NVIDIA_GPU_Computing_SDK/C"
"$ENV{NVSDKCOMPUTE_ROOT}/C"
"$ENV{NVSDKCUDA_ROOT}"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\NVIDIA Corporation\\Installed Products\\NVIDIA SDK 10\\Compute;InstallDir]"
"/Developer/GPU\ Computing/C"
)
cmake now finds my 4.0 SDK automatically.
But my build still fails to find cutil.h, even though it is there. $HOME/NVIDIA_GPU_Computing_SDK/C/common/inc/cutil.h. I had to add an include flag to the project to get it to finally work. CUDA_NVCC_FLAGS : -I/home/bill/NVIDIA_GPU_Computing_SDK/C/common/inc
Note: -I/$HOME/NVIDIA_GPU_Computing_SDK/C/common/inc does NOT work. (The env $HOME is set correctly.)