OK, so I am trying to connect an emulated (Through TSIM) LEON3 processor to a UART terminal. If I am not mistaken I believe I need to compile a C program to enable it to talk with a terminal as I am having difficulties doing it another way.
I found some source code for UART communication here and it all seems to be OK.
However, I am having issues compiling it using the SPARC Bare C Toolchain in Eclipse as it is saying that the windows.h file does not exist. Now I know it exists as I've compiled it successfully using the GCC Toolchain and can't find any similar cases on the web as to why this would be happening.
Is there anyone out there who has had a similar problem or knows the solution?
Additionally, if you know me to be doing the wrong thing in regards to the LEON3 UART comms, please let me know and I will just leave.
Thanks.
BCC is a cross compiler targeting standalone, LEON3- and LEON4-based environments. As a cross compiler, its job is to build binaries for a different environment than the one in which it runs.
Relevant header files describe functions available to a program in its runtime (target) environment. Build-environment libraries and their headers are irrelevant when cross compiling because the build and target environments differ. BCC is correct to expose only the headers for the environment for which it compiles, and that environment does not provide Windows API functions. If the code you're trying to build depends on the Windows API, then you'll need to modify it to remove that dependency, or else find something different.
On the other hand, I strongly suspect that you're going about this whole thing the wrong way. In particular, when you say,
I believe I need to compile a C program to enable it to talk with a terminal
it sounds like you think you're going to build some kind of helper program, but if that's your idea then either you're building it for the wrong environment or you have the wrong idea altogether.
If you want a Windows program that talks to the emulated machine, then you should be building that as a Windows program, and BCC doesn't do that. In that case, you should be using MinGW's gcc, or another C compiler for the emulator's host environment. Moreover, the host-side interface to the emulated environment's UART is an aspect of the emulator. I haven't a clue what emulator you're using, but it might not present the host (Windows) side of that interface as a UART, and it might not require using the Windows API at all.
Or if you indeed do intend to build a program for the standalone LEON3 target environment, then you need to understand that when it runs, it will be the only program that will be running in that environment. That's what "standalone" means -- no OS underneath, therefore no separate processes, and often not even multiple threads of execution. Thus, you do not need a helper program; you just need a program.
The BCC documentation talks about the libraries available there, and in particular, it describes how in that environment, file I/O is allowed only on the standard input and output streams, which are mapped to UART A. Thus, if you use BCC to build the program to run in the emulator, then you don't need to do anything special on that end to talk to the UART. You just use stdio functions directed at stdin and stdout.
On the third hand, if you are running an actual operating system in your emulated environment, then to build programs that run on it you should be using either a native compiler for that environment, in that environment, or else a cross compiler targeting that hosted environment. Either way, BCC is not such a compiler, but GCC might be. Anyway, since Windows does not run on LEON3, it's safe to say that if this is what you're trying to do then you still need something that does not depend on the Windows API.
Related
I'm studying computer engineering and we have a class called operating systems where they lecture us about how OSes handle stuff etc. This week we were given a homework which requests us to code a shell that works on Linux. The problem is, they tought us literally nothing on how to code a shell so we are supposed to do some research and figure it out.
I found this guide online and it seemed perfect to me: link
Code, with explanations, what else could I ask for.
Now, I'm using a Windows PC and I use Dev-C++ IDE with GCC compiler. Can I code a shell that works on Linux with my current setup or do I have to install Linux? Are there any major differences between how shells run on these OSes?
If you want to write a shell for Linux, you want to target GNU/Linux which is basically POSIX with some extensions.
Dev-C++ by default uses MinGW GCC as its compiler, providing a Win32 API.
Win32 and POSIX are completely and fundamentally different. A shell written for one will not even slightly resemble the other.
Instead, you have several options:
Dev-C++ can optionally use Cygwin GCC, providing a more GNU/Linux-like experience on Windows. You need to take great care not to rely on any Cygwin-specific functionality like how it automatically translates pathnames and line terminators. You'll still need access to a Linux install to verify that it works.
Windows 10 lets you install WSL, a more modern Linux compatibility layer for Windows. Dev-C++ doesn't explicitly states it support it, so you may need to edit and compile separately, and may lose debugging functionality. You'll still need access to a Linux install to verify that it works.
Just run Linux in a VM. The only thing to care about is getting your shell working.
I would suggest saving yourself a ton of trouble right now and just download/install an Ubuntu image in VirtualBox.
How can I compile C source code that uses standard functions like printf to run on a system without OS?
I tried using GCC to link statically but it seems I'm missing something. Can someone please explain how this can be done with GCC?
without OS
is difficult. your example printf() implies an output to a display. And this is (besides many other things) a task of an operatong system. Even the BIOS is an OS, and is capable of displaying text (and responding to keyboard presses).
So you have to decide, which minimalistic OS you are running your program on, and then you can crosscompile against that OS.
If by "without an OS" you mean you are compiling to run on an embedded platform then printf() will have no meaning for you because the platform does not have a standard output, which is where printf() is directed to on an OS (this is why it is in the stdio header).
Embedded platforms usually come with other means of outputting or monitoring data or states such as changing GPIO pin states, sending data to a communications peripheral (which will require you to write a driver for that) or maybe your program loader/IDE has some expression watch or feedback support.
Some embedded device manufacturers supply compilers for specific devices and in this case may come with the standard C library, but configuration will still be required to use printf().
First of all, I cannot use a debugger[1]. But I can access the Program Counter of a program, and can also compile the binary (written in C) with all the flags I need. And I can even change the code (although I prefer not to). Given a PC I want to be able to know which line it corresponds.
I'm sure there has to be an automated, practical, quick way to do this. But I haven't succeeded.
Edit: Forgot to mention: Linux system, binaries are PPC, host is i386. I do have access to PPC hardware.
[1] The application is being emulated, and it is cross compiled, I have a gdb in the host emulator. But I cannot connect a gdbserver on the emulated guest application. And real hardware is not an option, I'm trying to build a simulator based on the emulator.
If the binary is compiled with debugging information, then you can use the PC to find the right location in the source by groping through the ELF sections that contain the debug information. Automated, quick and practical aren't the terms that spring to mind for the process, though!
I need to write some C functions that will be called by a java program running on a CenOS Linux server, as part of a web application. The server is a hosted dedicated server sitting in another physical location, far away from me.
Do I need to develop the C stuff on the server directly, that is, doing development tunneling into the server? Or can I develop the C program on a Mac or Windows PC in my office, then once everything is working fine, store the final results on the server for use? If the latter, does it limit the choices for development environment in any way? That is, which compiler I should use, or any settings in the IDE or compiler I need to worry about since the development environment will be different than the production environment?
If I use Xcode version 3 on a Mac, it uses GCC by default, whereas Xcode version 4 uses LLVM-GCC to compile. Does the choice of compiler matter assuming I'm using C99 standard things? I don't want the code to be dependent on the development environment since I can't guarantee it'll stay the same in the future. Can I switch the compiler manually in Xcode somehow to verify the code works in GCC as well as LLVM?
Ignoring windows, things are pretty portable across mac/linux. If you develop it on mac in whatever development environment you want (I personally use TextWrangler and GCC from the command line.
Once you develop your software, it's a simple matter of copying the file to your remote server and compiling it there.
You may or may not need to change a few things. The only portability issue I've run into was mac's socket() using PF_ instead of AF_ (Mac will still accept AF_ but it doesn't advertise it in it's manpage, and other systems will not necessarily accept PF_) and sranddev() not being available on some systems; both of which were very easily resolvable.
If, however, you wanted to write the software directly on the remote box, its definitely not a hard thing to do, I would just ssh there and take your pick of text editors (usually vi or emacs) and compilers (usually gcc).
In general, for programs that are just traditional unix command line things, I tend to avoid Xcode as much as possible because it likes to hide things, and IMO its a good thing to actually understand what is going on behind the scenes. (Especially if you use other *nix systems.)
Whatever you do, it will need to be recompiled on the server.
You can probably create code that's runnable/testable under both environments, although you may have to #ifdef around compatibility issues. How much of that, if any, depends a lot on what you're actually writing.
Does the choice of compiler matter assuming I'm using C99 standard things?
Yes: Microsoft, AFAIK, still doesn't fully support C99 (but maybe that's changed in the latest MSVC). Also, you have to resist the temptation of using non-standard features just because they are there. OTOH, a local build env might force you to write portable programs.
The choice depends on how your program is going to communicate with the larger system, but developing at least parts locally is probably the most convenient option.
A CS course I'm taking online suggests students compile their source code and run tools like valgrind on the OS UNIX. I'm completely new to UNIX, Linux, their tools, and coding in c. I've made some attempts at installing FreeBSD 8.1 on VMWare Player 3.1.3, and even managed to get VMWare Tools running. But the FreeBSD documentation has led me down many dead-ends in accomplishing common tasks i.e. mounting an NFS or USB device. It turns out that the packages I need to make this happen aren't installed or configured, and I don't see any straight answer on how to install them.
So, if I'm using UNIX only as a tool to run gcc, g++, valgrind for this CS course, and these can be run on Linux instead, it seems like I can get the job done faster using Ubuntu Linux.
Can Linux be used to compile and run c code identically on UNIX, if compiled on Linux? Or if not, what are the differences to look for?
Thanks
For the novice-level C programmer such as OP, the difference of environment is negligible. Go ahead with Linux.
I think for purposes of the course you could run your programs and tools on Linux,
but I guess the reason your teacher wants you to use FreeBSD is so that you learn other things besides just coding up your problems
The two should be effectively the same. The only major difference you might see would be due to different versions being used. I would check to see what versions of gcc, g++ and valgrind the teacher is having you use, and make sure that you have the same version running on your install of Linux.
You can also use MinGW or Cygwin. You mentioned VMWare, so I'm guessing you're trying to just get an environment up and running in a windows environment. They both allow you to use the compiler and some of the tools without a full install of a Linux based system. In a CS course they would be more than enough.
The main differences too look for:
Compiling C / C++ is not machine independent. You need to have a small environment to compile on UNIX anyway if you need to submit compiled programs to your professor.
C / C++ is rather portable if you don't use anything that's non-portable. It's very hard to verify that you didn't use something that's different between the two machines, so you may wish to compile on UNIX to verify you didn't let an unavailable library (or an specific to the OS procedure, argument, behavior, bugs, etc.) slip into your code.
The vendor of make between the two machines may differ. This means that while the core of make will operate similarly, certain features might not be available in both. In reality, you probably won't use most of makes extended features, but in a worst case scenario you might opt to maintain multiple Makefiles or limit yourself to a common subset of features.
At the end of the day, it all boils down to what your professor will want. Odds are 95+% that you can do 100% of the work in Linux, but the prof's requirements or grading environment might be such that you will have to copy your code into a UNIX account to build the final "submission" executable. Considering that university UNIX accounts aren't nearly as portable as Linux on a laptop, the cost of the "final verification / porting" to the University computer is likely to be small compared to the convenience of working on your homework more hours than you can manage in a fixed lab.