Problems with sprintf and libgcc.a

Grant Edwards <grante@visi.com> wrote:
> On 2005-04-10, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:

> > 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.

> 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.

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".

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

> I've never been brave enough to hack on a specs file. 

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.

> 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.  

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).

> > It was supposed to be informed about these as part of the job of
> > porting GCC to that hardware platform. 

> If I had to port GCC to each hardware platform I'd never get
> anything done.  

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.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

In article <3bt522F6i0vl2U1@news.dfncis.de>, broeker@physik.rwth-
aachen.de says...
> Grant Edwards <grante@visi.com> wrote:
> > On 2005-04-10, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> 
> > > That's nothing a little hack of the 'specs' file couldn't fix.
> 
> > I've never been brave enough to hack on a specs file. 
> 
> 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.

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.

> > > It was supposed to be informed about these as part of the job of
> > > porting GCC to that hardware platform. 
> 
> > If I had to port GCC to each hardware platform I'd never get
> > anything done.  
> 
> 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.  

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? 

> 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.

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

Grant Edwards wrote:
> On 2005-04-10, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> 
>>Mayank Kaushik <prehistorictoad2k@yahoo.com> wrote:
>>
>>
>>>arm-elf-ld  -L --cref
>>
>>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.
> 
> 
> 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.
> 

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

-- 

Tauno Voipio
tauno voipio (at) iki fi

R Adsett <radsett@junk.aeolusdevelopment.cm> wrote:
> broeker@physik.rwth-aachen.de says...

[...]
> > command line you've never used before.  Nowadays, the syntax of spec
> > files format is even documented properly.

> It is?  That's good news, where?  

	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.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

On 2005-04-10, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:

>> I've never been brave enough to hack on a specs file. 
>
> 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.

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.

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

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

>>> It was supposed to be informed about these as part of the job of
>>> porting GCC to that hardware platform. 
>
>> If I had to port GCC to each hardware platform I'd never get
>> anything done.  
>
> 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.

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

> 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.

That's a good point.

-- 
Grant Edwards                   grante             Yow!  I just had my entire
                                  at               INTESTINAL TRACT coated
                               visi.com            with TEFLON!

In article <3btd61F6igslaU1@news.dfncis.de>, broeker@physik.rwth-
aachen.de says...
> R Adsett <radsett@junk.aeolusdevelopment.cm> wrote:
> > broeker@physik.rwth-aachen.de says...
> 
> [...]
> > > command line you've never used before.  Nowadays, the syntax of spec
> > > files format is even documented properly.
> 
> > It is?  That's good news, where?  
> 
> 	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.

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

http://www.cse.ohio-state.edu/cgi-bin/info/info/gcc,Spec%20Files

which I will take a look at.

Robert

R Adsett wrote:
> broeker@physik.rwth-aachen.de says...
>
... snip ...
>>
>>       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.
> 
> 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
> 
> http://www.cse.ohio-state.edu/cgi-bin/info/info/gcc,Spec%20Files
> 
> which I will take a look at.

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.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

R Adsett <radsett@junk.aeolusdevelopment.cm> wrote:
> In article <3btd61F6igslaU1@news.dfncis.de>, broeker@physik.rwth-
> aachen.de says...

> >       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.

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

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

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

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?

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

In article <4259C29C.8F2657CD@yahoo.com>, cbfalconer@yahoo.com says...
> R Adsett wrote:
> > broeker@physik.rwth-aachen.de says...
> >
> ... snip ...
> >>
> >>       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.
> > 
> > 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
> > 
> > http://www.cse.ohio-state.edu/cgi-bin/info/info/gcc,Spec%20Files
> > 
> > which I will take a look at.
> 
> 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.

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

In article <3bv8v4F695at9U3@news.dfncis.de>, broeker@physik.rwth-
aachen.de says...
> R Adsett <radsett@junk.aeolusdevelopment.cm> wrote:
> > In article <3btd61F6igslaU1@news.dfncis.de>, broeker@physik.rwth-
> > aachen.de says...
> 
> > >       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.
> 
> > Hmm, all that gets me are some errors and in particular 
> 
> Come, now, you sure know that "some errors" is no way to report a
> problem...

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.

> 
> > Unable to find node referenced by `Spec Files' in
> > `(gcc.info.gz)Invoking GCC'.
> 
> 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?

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