Re: Unomitted frame pointers

Re: Unomitted frame pointers

[Thomas R. Truscott]

Off-topic, but the hello.c program does:

	write(2, "Hello World!\n\0", 16);

The string length is 15, not 16.
It would be nice if gcc issued warnings for compile-time constant
string/length pairs where the length is too large.

I do that in my local copy of gcc, and it routinely finds
coding mistakes for memcpy().
Perhaps this could somehow be an "attribute" that gcc can check.

(Hmm, the attribute thing is too limited, what would be really
nice is a way to write code that does general compile-time argument
checking.  Then one could do more thorough checks such as is
done for printf/scanf.  And the same code could be invoked
at run time ... oops, way off topic.)

Tom Truscott

Re: Unomitted frame pointers

[jlh]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]


> Off-topic, but the hello.c program does:
> 	write(2, "Hello World!\n\0", 16);
> The string length is 15, not 16.

15 is what gets allocated for storing the string (counting
the additional \0 that always gets appened to string constants).
But neither the explicit nor the implicit \0 should be printed
to the console, so the call should definitely read:

     write(2, "Hello World!\n", 13);

jlh

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

RE: Unomitted frame pointers

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of jlh
> Sent: 10 December 2004 16:05
> To: Thomas R. Truscott

> > Off-topic, but the hello.c program does:
> > 	write(2, "Hello World!\n\0", 16);
> > The string length is 15, not 16.
> 
> 15 is what gets allocated for storing the string (counting
> the additional \0 that always gets appened to string constants).
> But neither the explicit nor the implicit \0 should be printed
> to the console, so the call should definitely read:
> 
>      write(2, "Hello World!\n", 13);
> 
> jlh


  Except of course on targets where '\n' expands to a two char CR-LF
combination.

  So really the safe way to code this is

#define HELLOSTRING "Hello World!\n"

      write (2, HELLOSTRING, strlen(HELLOSTRING)-1);

and let the compiler statically compute the string length for you at
compiletime.  The #define is used to make sure we don't end up with two copies
of the string that get out of sync, as would be bound to happen sooner or later
if we wrote

      write (2, "Hello World!\n", strlen("Hello World!\n")-1); 

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Unomitted frame pointers

[Nathan Sidwell]

Dave Korn wrote:
>>-----Original Message-----
>>From: gcc-owner On Behalf Of jlh

>>     write(2, "Hello World!\n", 13);

> 
>   Except of course on targets where '\n' expands to a two char CR-LF
> combination.

you're smoking something :)

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

RE: Unomitted frame pointers

[Dave Korn]

> -----Original Message-----
> From: Nathan Sidwell 
> Sent: 10 December 2004 16:30

> Dave Korn wrote:
> >>-----Original Message-----
> >>From: gcc-owner On Behalf Of jlh
> 
> >>     write(2, "Hello World!\n", 13);
> 
> > 
> >   Except of course on targets where '\n' expands to a two char CR-LF
> > combination.
> 
> you're smoking something :)
> 


  Not at all.  That's why sizeof(char) sometimes returns 1, and sometimes
returns 2, depending on the char!

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Unomitted frame pointers

[Nathan Sidwell]

Dave Korn wrote:
>>-----Original Message-----
>>From: Nathan Sidwell 
>>Sent: 10 December 2004 16:30
> 
> 
>>Dave Korn wrote:
>>
>>>>-----Original Message-----
>>>>From: gcc-owner On Behalf Of jlh
>>
>>>>    write(2, "Hello World!\n", 13);
>>
>>>  Except of course on targets where '\n' expands to a two char CR-LF
>>>combination.
>>
>>you're smoking something :)
>>
>   Not at all.  That's why sizeof(char) sometimes returns 1, and sometimes
> returns 2, depending on the char!

I stand by my earlier assertion :)

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

[OT] RE: Unomitted frame pointers

[Dave Korn]

> -----Original Message-----
> From: Nathan Sidwell 
> Sent: 10 December 2004 17:54
> To: Dave Korn
> Cc: 'jlh'; 'Thomas R. Truscott'; gcc
> Subject: Re: Unomitted frame pointers
> 
> Dave Korn wrote:
> >>-----Original Message-----
> >>From: Nathan Sidwell 
> >>Sent: 10 December 2004 16:30

[Cc line trimmed owing to OT-ness]

> > 
> >>Dave Korn wrote:
> >>
> >>>>-----Original Message-----
> >>>>From: gcc-owner On Behalf Of jlh
> >>
> >>>>    write(2, "Hello World!\n", 13);
> >>
> >>>  Except of course on targets where '\n' expands to a two 
> char CR-LF
> >>>combination.
> >>
> >>you're smoking something :)
> >>
> >   Not at all.  That's why sizeof(char) sometimes returns 1, 
> and sometimes
> > returns 2, depending on the char!
> 
> I stand by my earlier assertion :)
> 

  I presume now would not be a good time to explain my theories about how it
also varies with latitude, longitude, and phase of the moon ?


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Unomitted frame pointers

[Andreas Schwab]

"Dave Korn" <dave.korn@artimi.com> writes:

>   So really the safe way to code this is
>
> #define HELLOSTRING "Hello World!\n"
>
>       write (2, HELLOSTRING, strlen(HELLOSTRING)-1);

No, it's

        write (2, HELLOSTRING, strlen(HELLOSTRING));

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: Unomitted frame pointers

[Dave Korn]

> -----Original Message-----
> From: Andreas Schwab [mailto:schwab@suse.de] 
> Sent: 10 December 2004 16:33

> "Dave Korn" writes:
> 
> >   So really the safe way to code this is
> >
> > #define HELLOSTRING "Hello World!\n"
> >
> >       write (2, HELLOSTRING, strlen(HELLOSTRING)-1);
> 
> No, it's
> 
>         write (2, HELLOSTRING, strlen(HELLOSTRING));
> 
> Andreas.
> 


  Duh.  Yes, of course I needn't allow for the NUL-terminator......


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Unomitted frame pointers

[Thomas R. Truscott]

>         write (2, HELLOSTRING, strlen(HELLOSTRING));

People sometimes mismatch the string names, e.g.:

          write (2, HELLOSTRING, strlen(JELLOSTRING));
                                        ^

To reduce that hazard we have a macro:

#define TEXTARG(s)    s, (int)strlen(s)

          write (2, TEXTARG (HELLOSTRING));

But it looks odd, and people don't use it as much as they could.

Tom Truscott

P.S.  here is another thing gcc misses:

          memcpy("hi", p, 2);  /* "cannot modify string literal" */

Re: Unomitted frame pointers

[Paul Brook]

On Friday 10 December 2004 16:54, Thomas R. Truscott wrote:
> P.S.  here is another thing gcc misses:
>
>           memcpy("hi", p, 2);  /* "cannot modify string literal" */

Works for me:

paul@wren:~$ gcc -Wwrite-strings test.c
test.c: In function 'main':
test.c:9: warning: passing argument 1 of 'memcpy' discards qualifiers from 
pointer target type

Paul

Re: Unomitted frame pointers

[Kai Henningsen]

paul@codesourcery.com (Paul Brook)  wrote on 10.12.04 in <200412101726.33264.paul@codesourcery.com>:

> On Friday 10 December 2004 16:54, Thomas R. Truscott wrote:
> > P.S.  here is another thing gcc misses:
> >
> >           memcpy("hi", p, 2);  /* "cannot modify string literal" */
>
> Works for me:
>
> paul@wren:~$ gcc -Wwrite-strings test.c
> test.c: In function 'main':
> test.c:9: warning: passing argument 1 of 'memcpy' discards qualifiers from
> pointer target type

Would it be hard to say what qualifier(s) here? I'm sure that would make  
many programmers go "duh!" significantly faster in those moments.

MfG Kai

Re: Unomitted frame pointers

[Sam Lauber]

How can the linker combine them? The _program_ is way outside GCC's control. The assembler and linker don't modify the generated assembly. Otherwise, BFD and binutils would become very twisted up, and thus make the assembler world on GCC diffrent than it is now.

----- Original Message -----
From: "Andreas Schwab" <schwab@suse.de>
To: "Sam Lauber" <sam124@operamail.com>
Subject: Re: Unomitted frame pointers
Date: Sat, 11 Dec 2004 16:44:54 +0100

> 
> "Sam Lauber" <sam124@operamail.com> writes:
> 
> > We would end up with two copies of the string. #defines are
> > preprocessed, so it would expand to the second thing.
> 
> And the compiler and the linker combine them again.
> 
> > The _safe_ way to do it is
> >
> > char str = "Hello World!\n";
> > write(2, str, strlen(str)-1);
> 
> Why would you want to exclude the trailing newline?
> 
> Andreas.
> 
> --
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

Re: Unomitted frame pointers

[Ian Lance Taylor]

"Sam Lauber" <sam124@operamail.com> writes:

> How can the linker combine them? The _program_ is way outside GCC's
> control. The assembler and linker don't modify the generated
> assembly. Otherwise, BFD and binutils would become very twisted up,
> and thus make the assembler world on GCC diffrent than it is now.

In fact, when the same string appears in multiple object files, recent
version of the GNU linker will combine them.  Try it.  If you want to
figure out how it works, look closely at the generated assembly code
and at the linker source code.

When somebody with experience tells you that something is so, it
behooves to at least give it a try before you claim that it can not be
so.

Ian

Re: Unomitted frame pointers

[Sam Lauber]

Do you know about macro expansion? CPP would make it seperate strings. So there would be (simplified);

.LC0:
.string "Hello World!\n"
.LC1:
.string "Hello World!\n"
main:
; push LC0 into strlen
push #.LC0, (%eax)
call strlen
; push LC1 into write
push #.LC1, (%ebx)
...

It automatically happens, and I don't know of any way to avoid cpp from macro-expanding it to that. Though inlining would reduce it to the C code

int main(void)
{
       char str1 = "Hello World!\n";
       char str2 = "Hello World!\n";
       int str_len = 0;
       while (*str1++ != "\0")
              str_len++;
       write(2, str2, str_len);
}

embedding strlen inside main. Or even more optimization

int main(void)
{
        write(2, "Hello World!\n", 13);
}

which is back where we started.

Samuel Lauber

----- Original Message -----
From: "Nathan Sidwell" <nathan@codesourcery.com>
To: "Sam Lauber" <sam124@operamail.com>
Subject: Re: Unomitted frame pointers
Date: Sat, 11 Dec 2004 15:40:38 +0000

> 
> Sam Lauber wrote:
> > We would end up with two copies of the string. #defines are 
> > preprocessed, so it would expand to the second thing. The _safe_ 
> > way to do it is
> Why do you think you'd get two copies of the string?
> 
> >
> > char str = "Hello World!\n";
> type mismatch error
> 
> > write(2, str, strlen(str)-1);
> off by one error
> 
> nathan
> -- Nathan Sidwell    ::   http://www.codesourcery.com   ::     
> CodeSourcery LLC
> nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

Re: Unomitted frame pointers

[Nathan Sidwell]

Sam Lauber wrote:
> Do you know about macro expansion? CPP would make it seperate strings. So there would be (simplified);

Have you actually TRIED this ?

> int main(void)
> {
>        char str1 = "Hello World!\n";
>        char str2 = "Hello World!\n";
>        int str_len = 0;
>        while (*str1++ != "\0")
>               str_len++;
>        write(2, str2, str_len);
> }

This program won't compile.  How do you know what assembly you'd get?

I think you're hypothesizing with no knowledge of the internals of the compiler,
or actual experimentation.

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: Unomitted frame pointers

[Peter Barada]

>Do you know about macro expansion? CPP would make it seperate strings. So there would be (simplified);
>
>.LC0:
>.string "Hello World!\n"
>.LC1:
>.string "Hello World!\n"
>main:
>; push LC0 into strlen
>push #.LC0, (%eax)
>call strlen
>; push LC1 into write
>push #.LC1, (%ebx)
>...
>
>It automatically happens, and I don't know of any way to avoid cpp from macro-expanding it to that. Though inlining would reduce it to the C code
>
>int main(void)
>{
>       char str1 = "Hello World!\n";
>       char str2 = "Hello World!\n";
>       int str_len = 0;
>       while (*str1++ != "\0")
>              str_len++;
>       write(2, str2, str_len);
>}
>
>embedding strlen inside main. Or even more optimization
>
>int main(void)
>{
>        write(2, "Hello World!\n", 13);
>}

Once I reduced your testcase to:

#include <string.h>

int main(void)
{
       char *str1 = "Hello World!\n";

       write(2, str1, strlen(str1));
}


And compiled it off the current mainline for --target=m68k-elf I get:

	.section	.rodata.str1.1,"aMS",@progbits,1
.LC0:
	.string	"Hello World!\n"
	.text
	.align	2
	.globl	main
	.type	main, @function
main:
	link.w %fp,#0
	pea 13.w        ; <<<< strlen(str1)
	pea .LC0
	pea 2.w
	jbsr write
	lea (12,%sp),%sp
	unlk %fp
	rts


If you notice, the strlen is completely removed and replaced with 'pea
13.w' which does what you hope it does.

Even if I changed the code to:

#include <string.h>

#define STR "Hello World!\n"
int main(void)
{
       char *str1 = STR;

       write(2, str1, strlen(STR));
}

GCC produces the same code.  Even gcc-2.96 on my Linux x86 box
knows to convert the strlen call into a constant.

Use the standard named functions since GCC is smart enough to figure
out(with optimization enabled) that 'strlen(str1)' is 13 since between
the declaration of str1 and the call to strlen, str1 did not change
and GCC knows what strlen of a constant string is, or a pointer to a
string constant that it see doesn't change between its assignment and
the invocation.

Hopefully this helps...

-- 
Peter Barada
peter@the-baradas.com

Re: Unomitted frame pointers

[Sam Lauber]

Then why does -fomit-frame-pointer work on x86 at all? Then that option to omit a frame pointer shall be omitted ;). At least on x86. As for ABI, I simply don't understand this kind of stuff, because there is not enough information and documentation, and I don't have the time to check out the GCC source tree every time I want to look at something. And I _still_ don't recall any warning. I ran strings on GCC, and the only thing I saw was in the builtin specs saying "-pg and -fomit-frame-pointer are incompatible". You must be using 4.0 or 3.3. Why does it have to dynamically align the frame pointer? And _I'm_ not using an old 8086, I've got a Pentium III! I find your comment a bit insulting. And what's the valid reason this time?

Samuel Lauber

----- Original Message -----
From: "Eric Botcazou" <ebotcazou@libertysurf.fr>
To: "Sam Lauber" <sam124@operamail.com>
Subject: Re: Unomitted frame pointers
Date: Sat, 11 Dec 2004 09:08:31 +0100

> 
> > What messages?
> 
> I already posted the same advice once.
> 
> >  I HAD to call my function main, because it was main.
> 
> You don't understand.  Don't do your experiment on a function called 'main',
> it is very special in C.  The bottom line is that it must dynamically align
> the stack pointer on x86 because of an antiquated ABI, thus preventing
> -fomit-frame-pointer to be effective.
> 
> And keep in mind that GCC has been working on x86 for more than 15 years, so
> it can't do as dumb things as you think it does.  There is almost always a
> valid reason.
> 
> --
> Eric Botcazou

-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

Re: Unomitted frame pointers

[Eric Botcazou]

> Then why does -fomit-frame-pointer work on x86 at all? Then that option to
> omit a frame pointer shall be omitted ;). At least on x86.

Do the following experiment: rename your function 'my_main', recompile with -S 
-fomit-frame-pointer and inspect the assembly code.

> Why does it have to dynamically align the frame pointer? And _I'm_ not using
> an old 8086, I've got a Pentium III! 

Precisely because you're using a modern x86 processor, which features SSE 
instructions and the likes.

-- 
Eric Botcazou

Re: Unomitted frame pointers

[Robert Dewar]

Sam Lauber wrote:

Sam, you really don't have the basic knowledge here. You really need to understand
ABI's in general, and the x86 ABI in particular, or you are not going to understand
what is going on.

-fomit-frame-pointer means omit the frame pointer when it is possible. It often
is not possible, in which case the switch is ignored. For example, it obviously
cannot be omitted if there is an alloca call.

> because there is not enough information and documentation

You need to track down the information, you really can't expect to
understand much until you do understand the ABI.

> Why does it have to dynamically align the frame pointer?

Because this is required by the ABI, if you fail to align the stack
pointer, then a lot of code will be unnecessarily ineffcient, and
code using newer instructions (e.g. the new floating-point instructions)
will fail at run time.

> I find your comment a bit insulting

That's actually almost an amusing misunderstanding. Eric did not say that
your machine was obsolete. He said that the generated code was accomodating
an antiquated ABI. That's totally and completely different. He was not
blaming you for anything!

The issue is that the original ABI did not forsee architecture developments.
For example, those requiring greater stack alignment. This is indeed quite
a mess, since you really need this greater alignment. What is happening is
that there are really two ABI's, the old antiquated one, maintained because
old software never dies, and the new one which accomodates the new instructions.
The main procedure in gcc is where the bridge is built between these two ABI's,
which is why the tack has to be dynamically aligned in main.

I assume you do understand alignment requirements in general. If not, you
will really be at sea here. I would recommend reading a book on architecture.

begin shameless plug:
My book "Microprocessors: A Programmers View", with Matthew Smosna, would
probably be at just the right level. It's out of print now, but Amazon lists
used copies from $1.98. [so I am not hunting for royalties here :-)]. One of
these days I should make an updated version of this book.
end shamless plug.

Re: Unomitted frame pointers

[Ranjit Mathew]

Robert Dewar wrote:
[...]
> begin shameless plug:
> My book "Microprocessors: A Programmers View", with Matthew Smosna, would
> probably be at just the right level. It's out of print now, but Amazon lists
> used copies from $1.98. [so I am not hunting for royalties here :-)]. One of
> these days I should make an updated version of this book.
> end shamless plug.

That book was really very good and taught me a lot - thank you!

I really wish it hadn't gone out of print and that you guys
update it for newer microprocessors! ~sigh~

Ranjit.

-- 
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://ranjitmathew.hostingzero.com/

Re: Unomitted frame pointers

[Robert Dewar]

Ranjit Mathew wrote:

>>My book "Microprocessors: A Programmers View", with Matthew Smosna, would

> That book was really very good and taught me a lot - thank you!

Thank you for the nice note
> 
> I really wish it hadn't gone out of print and that you guys
> update it for newer microprocessors! ~sigh~

OK, fair enough, request noted. One of the reasons this did not get
updated was that Matthew Smosna, my coauthor, died of a stroke a
couple of years after the book came out. He was in his mid forties,
so this was really tragic and unexpected.

I still would very much like to get around to producing a new
edition. Now that I have retired from teaching (to concentrate
more on my company, and anyway, 36 years of teaching is enough),
perhaps I will find time to do it :-)

It's actually quite interesting to read that (now 13 year old)
book today. A lot is still exactly right, but somethings are
spectacularly wrong (e.g. the speculation that perhaps we would
be able to get CMOS working up to 100 Megahertz, but that likely
other technologies would be required for higher speeds :-) :-)

Robert Dewar

Re: Unomitted frame pointers

[Ben Elliston]

Ranjit Mathew <rmathew@gmail.com> writes:

> > My book "Microprocessors: A Programmers View", with Matthew Smosna, would
> > probably be at just the right level. It's out of print now, but Amazon lists
> > used copies from $1.98. [so I am not hunting for royalties here :-)]. One of
> > these days I should make an updated version of this book.
> > end shamless plug.
> 
> That book was really very good and taught me a lot - thank you!

> I really wish it hadn't gone out of print and that you guys update
> it for newer microprocessors! ~sigh~

Although it's getting a late out of date itself now, I found Daniel
Tabak's "Advanced Microprocessors" to be an excellent reference, too.
Like others, it contains a number of case studies.

Ben

RE: Unomitted frame pointers

[Sam Lauber]

We would end up with two copies of the string. #defines are preprocessed, so it would expand to the second thing. The _safe_ way to do it is

char str = "Hello World!\n";
write(2, str, strlen(str)-1);

Then we can be sure that it refers to the same physical address in RAM. "Two copies" is when the strings are positioned at diffrent non-overlapping addresses. Though optimization and inlining might mess it up.

Samuel Lauber

----- Original Message -----
From: "Dave Korn" <dave.korn@artimi.com>
To: "'jlh'" <jlh@gmx.ch>, "'Thomas R. Truscott'" <trt@cs.duke.edu>
Subject: RE: Unomitted frame pointers
Date: Fri, 10 Dec 2004 16:23:59 -0000

> 
> > -----Original Message-----
> > From: gcc-owner On Behalf Of jlh
> > Sent: 10 December 2004 16:05
> > To: Thomas R. Truscott
> 
> > > Off-topic, but the hello.c program does:
> > > 	write(2, "Hello World!\n\0", 16);
> > > The string length is 15, not 16.
> >
> > 15 is what gets allocated for storing the string (counting
> > the additional \0 that always gets appened to string constants).
> > But neither the explicit nor the implicit \0 should be printed
> > to the console, so the call should definitely read:
> >
> >      write(2, "Hello World!\n", 13);
> >
> > jlh
> 
> 
>    Except of course on targets where '\n' expands to a two char CR-LF
> combination.
> 
>    So really the safe way to code this is
> 
> #define HELLOSTRING "Hello World!\n"
> 
>        write (2, HELLOSTRING, strlen(HELLOSTRING)-1);
> 
> and let the compiler statically compute the string length for you at
> compiletime.  The #define is used to make sure we don't end up with two copies
> of the string that get out of sync, as would be bound to happen 
> sooner or later
> if we wrote
> 
>        write (2, "Hello World!\n", strlen("Hello World!\n")-1);
> 
>      cheers,
>        DaveK
> --
> Can't think of a witty .sigline today....

-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

Re: Unomitted frame pointers

[Nathan Sidwell]

Sam Lauber wrote:
> We would end up with two copies of the string. #defines are preprocessed, so it would expand to the second thing. The _safe_ way to do it is
Why do you think you'd get two copies of the string?

> 
> char str = "Hello World!\n";
type mismatch error

> write(2, str, strlen(str)-1);
off by one error

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: Unomitted frame pointers

[Andreas Schwab]

"Sam Lauber" <sam124@operamail.com> writes:

> We would end up with two copies of the string. #defines are
> preprocessed, so it would expand to the second thing.

And the compiler and the linker combine them again.

> The _safe_ way to do it is
>
> char str = "Hello World!\n";
> write(2, str, strlen(str)-1);

Why would you want to exclude the trailing newline?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Unomitted frame pointers

[Sam Lauber]

I HAD to call my function main, it was the main routine. Compiling it with -W -Wall only gave me "implict declaration of function `write'.

Samuel Lauber

----- Original Message -----
From: "Eric Botcazou" <ebotcazou@libertysurf.fr>
To: "Sam Lauber" <sam124@operamail.com>
Subject: Re: Unomitted frame pointers
Date: Fri, 10 Dec 2004 08:19:17 +0100

> 
> > Clearly some one (or some code) isn't doing its job! The original C code is
> > attached. I thought -fomit-frame-pointer is supposed to OMIT the frame
> > pointer!
> 
> You didn't read all the messages.  Do not call your function 'main'.
> 
> --
> Eric Botcazou

-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

Unomitted frame pointers

[Sam Lauber]

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

Going back to useless assembly, a low-level Hello World with -fno-omit-frame-pointer:

        .file   "hello.c"
        .section        .rodata
.LC0:
        .string "Hello World!\n"
        .string ""
        .text
.globl main
        .type   main, @function
main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $24, %esp
        andl    $-16, %esp
        movl    $0, %eax
        addl    $15, %eax
        addl    $15, %eax
        shrl    $4, %eax
        sall    $4, %eax
        subl    %eax, %esp
        movl    $16, 8(%esp)
        movl    $.LC0, 4(%esp)
        movl    $2, (%esp)
        call    write
        movl    $0, %eax
        leave
        ret
        .size   main, .-main
        .section        .note.GNU-stack,"",@progbits
        .ident  "GCC: (GNU) 3.4.3"

And the same C code with -fomit-frame-pointer:

        .file   "hello.c"
        .section        .rodata
.LC0:
        .string "Hello World!\n"
        .string ""
        .text
.globl main
        .type   main, @function
main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $24, %esp
        andl    $-16, %esp
        movl    $0, %eax
        addl    $15, %eax
        addl    $15, %eax
        shrl    $4, %eax
        sall    $4, %eax
        subl    %eax, %esp
        movl    $16, 8(%esp)
        movl    $.LC0, 4(%esp)
        movl    $2, (%esp)
        call    write
        movl    $0, %eax
        leave
        ret
        .size   main, .-main
        .section        .note.GNU-stack,"",@progbits
        .ident  "GCC: (GNU) 3.4.3"

Clearly some one (or some code) isn't doing its job! The original C code is attached. I thought -fomit-frame-pointer is supposed to OMIT the frame pointer!

Samuel Lauber
-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

[-- Attachment #2: hello.c --]
[-- Type: application/octet-stream, Size: 65 bytes --]

int main(void)
{
	write(2, "Hello World!\n\0", 16);
	return 0;
}

Re: Unomitted frame pointers

[Eric Botcazou]

> Clearly some one (or some code) isn't doing its job! The original C code is
> attached. I thought -fomit-frame-pointer is supposed to OMIT the frame
> pointer!

You didn't read all the messages.  Do not call your function 'main'.

-- 
Eric Botcazou

Re: Unomitted frame pointers

[Richard Guenther]

On Fri, 10 Dec 2004 06:26:26 +0100, Sam Lauber <sam124@operamail.com> wrote:
> Going back to useless assembly, a low-level Hello World with -fno-omit-frame-pointer:
> And the same C code with -fomit-frame-pointer:

Try enabling optimization :)  After some trying I found you're using gcc 3.4
or 4.0 without any -O option (try using -O2 for a start).

Richard.