Problems with sprintf and libgcc.a

Generaly speaking, it's rarely a good idea to invoke 'ld' yourself when linking C or C++ programs. Have 'gcc' invoke it for you instead. Unless the GCC port is buggy, it'll know how to invoke ld correctly. In particular, it'll put in all necessary references -lgcc, -lc and the startup file(s) for you.

Your description shows that the GROUP() thing you put into the linker script didn't have any effect at all.

The problems with memory space overlaps and such suggest that your linker script is probably not correct, or at least not compatible with the GCC output you use it on.

I've rarely found that to be true when working in an embedded environment. I've always had to use a custom linker script and disable most of the default startup file linkage.

How does gcc know what startup files to use for my hardware platform? Likewise, I don't want gcc linking in a "libc" file behind my back. I don't really even like it pulling a libgcc file out of it's hat either.

Please do not call ld directly, use arm-elf-gcc to link, instead.

These are entries into the GCC support library, libgcc.a. If you used the proper command line, you'd get them correct.

This is an entry into the C runtime library, which would also be included if you used gcc to link.

The linker script can be included with the -Wl switch.

--- snip snip ---

You do not have enough memory for your code and data. Prune the code or get more RAM.

Depending on your version of the C runtime, use of sprintf() may hoist in the whole file system interface and dynamic memory allocation, which are alone more than your 12 kbytes.

===SNIP===

You are using an OS now (Linux). All of the AT91F_' initialization stuff has been performed even before Linux got bootloaded. You need to use a makefile, link script, etc. that one would use to build a Linux application, not something that would be executed shortly after RESET is released.

-- Dan Henry

In general, I'd have to disagree on this point. I'd rather know what my tools are doing rather than have them do it behind my back. I've found that the more specific your needs and the more you deviate from the hosted model of the particular model the more likely know-it-all compile drivers are to get it wrong.

Robert

I did write "generally speaking" for a reason. This may indeed not as strictly true in embedded work as it is for hosted-environment GCCs, but it's still worth to be kept in mind.

The rationale behind letting GCC invoke ld is that this is how GCC is supposed to work --- it makes certain assumptions about the target platform, and some of those are reflected in pieces of the ld invocation composed by the "compiler driver program", gcc, including things like specs file, linker script, startup files, libgcc.a and libc. Not letting GCC do this effectively means you're fighting your tools, instead of configuring them correctly.

That's nothing a little hack of the 'specs' file couldn't fix.

It was supposed to be informed about these as part of the job of porting GCC to that hardware platform. If that job was never properly completed, you'll have to do keep telling it on each invocation.

Knowing what they're doing is one thing --- that's what gcc and ld each have a '-v' switch for. It's a totally different thing to jump in and do-it-yourself every single time, just because you don't believe the compiler driver can get it right. Our OP clearly demonstrates that individual programmers can get that completely wrong at least as easily as the GCC porters.

Maybe you work a lot differently than I do, but I don't want to build a different version of GCC for every variant of a core that I program.

Just let me provide those and let the compiler produce the object code from the source. That seems a fair and equitable division of responsibilities to me :)

Robert

I have found it handy command line options to ask gcc what library files it thinks it should use for libgcc, libc, libm, etc. That allows one to manually link in files that are automatically selected by gcc based on architecture options.

I've never been brave enough to hack on a specs file. That's proably the right way to do it, but it assumes that a given port of the compiler will only be used for a single project on a single hardware platform. I'm often using the same compiler for multiple projects that have different linkage requirements.

If I had to port GCC to each hardware platform I'd never get anything done. I use a single arm-elf-gcc port for a half-dozen different target platofrms.

Yup, that's what makefiles are for.

It won't give you all the machinery behind what it'll output in a given case, though (most of which is encoded in the specs file). E.g. looking at what "gcc -v -O2 -g3 -Wall foo.c" does won't tell you much of anything about what it might do for "gcc -v -O0 bar.cpp".

If you're brave enough to hack linker scripts, you can brave spec files, too. It's no more difficult to read and fiddle with a specs file than it'd be to second-guess what gcc would do for a given command line you've never used before. Nowadays, the syntax of spec files format is even documented properly.

The specs file is (among other things) GCC's way of encoding the dependencies between compile-time flags and linker invocations.

No. It only assumes that you're prepared to pass gcc a suitable specs file for each of them. You don't even have to write a complete specs file of your own --- you can override only those parts that need changing, and you can start with the existing specs file of the GCC you're using (or a --dumpspecs, if it's using the integrated one).

I don't think it's significantly harder to do the port than to experiment with your general-purpose GCC until it fits the new platform. It involves nothing more than to formalize the knowledge you have about that platform a little more strictly. It's an exercise in putting information in one place (the GCC target specification) rather than repeating it in the Makefile of every piece of software you'll ever write to run on that particular target.

It is? That's good news, where? Documentation is GNUs greatest weakness.

I didn't find GCCs linker scripts particularly difficult other than a marked absence of information on what sections the compiler will produce. They are certainly nor more difficult than any other linker script I've worked with. And at some point they are needed in order to deal with application specific memory maps, such as forcing particular information to a particular location.

Experiment???

All I do is call GCC to compile and then call ld to link in the appropriate startup and libraries with the compiled source and memory map. Why would that involve any experimentation?

Since the repeat at most involves an include of the appropriate definitions (not even a cut and paste), I don't see that as particularly burdensome. And the information is only in one place, the included file.

Robert

My vote to this, too. No need to re-build GCC & co for each target system.

The trick is to use -Wl for gcc command line (in Makefile):

LDFLAGS = -g -nostartfiles -Wl,-Map=$(TRG).map,--cref,-T,aif.ld

info gcc "Invoking GCC" "Spec Files"

(of GCC-3.4.1), or in the equivalent space of whatever format of the docs you're looking at.

But since I've got to write a linker script anyway, why bother with a specs file? I don't really see much of an advantage. It seems simpler to have the target-specific stuff in one file.

It's an interesting idea. I'll have to try it on my next project.

Not sure what you mean. I don't have to experiment with gcc at all. I just write a linker script.

That's a good point.

Hmm, all that gets me are some errors and in particular

Unable to find node referenced by `Spec Files' in `(gcc.info.gz)Invoking GCC'.

I did find

which I will take a look at.

Robert

... snip ...

Sounds as if you haven't got the info system properly installed. "Info" by itself should bring up a master menu and an optional tutorial.

Come, now, you sure know that "some errors" is no way to report a problem...

That means you have info installed, and a gcc info file installed in a place where info finds it --- but it's not the one for a recent GCC. There's a reasion I mentioned the version number being referred to, see?

Seems likely, although it's a straightforward cygwin install.

I just did a little more exploration and it seems that some of the nodes are missing and that's one of them. Odd, I'll have to fix that. In any case the web link seems to be the same source.

Robert

You're right, I was brushing quickly past it since they weren't visible long enough to decipher. Which just left the following which yo kindly deciphered.

Ahh, I'll have to update, although as a documentation medium info doesn't shine. In any case the web link I found does seem to be what you were referring to. It'll do for my initial explorations.

Robert