Saving arguments on the stack

Saving arguments on the stack

[Knittel, Brian]

Hi,

I'd like to force the compiler to store arguments on the stack with otherwise optimized code.

I found a refernce in the archives (form 2001) for using -0 (no optimization). Has anyone found another way to do this?

Thanks,

--Brian

Saving arguments on the stack

[Knittel, Brian]

Hi,

I'd like to force the compiler to store arguments on the stack with otherwise optimized code.

I found a refernce in the archives (form 2001) for using -0 (no optimization). Has anyone found another way to do this?

Thanks,

--Brian

Re: Saving arguments on the stack

[Kevin D. Kissell]

Knittel, Brian wrote:
> Hi,
> 
> I'd like to force the compiler to store arguments on the stack with otherwise optimized code.
> 
> I found a refernce in the archives (form 2001) for using -0 (no optimization). Has anyone found another way to do this?

If I recall correctly, if you specify -g to enable debugger support,
the subroutine prologues store the arguments into their stack slots,
even if a higher level of optimization is otherwise specified.

		Regards,

		Kevin K.

Re: Saving arguments on the stack

[Nigel Stephens]

Kevin D. Kissell wrote:

> Knittel, Brian wrote:
>
>> Hi,
>>
>> I'd like to force the compiler to store arguments on the stack with 
>> otherwise optimized code.
>>
>> I found a refernce in the archives (form 2001) for using -0 (no 
>> optimization). Has anyone found another way to do this?
>
>
> If I recall correctly, if you specify -g to enable debugger support,
> the subroutine prologues store the arguments into their stack slots,
> even if a higher level of optimization is otherwise specified.


'Fraid not: the -g option only adds debug info to the object file, it 
shouldn't alter the generated code. Using -O0 will certainly store 
everything on the stack, but it also won't be "with otherwise optimized 
code".


Nigel

Re: Saving arguments on the stack

[Ralf Baechle]

On Tue, Nov 22, 2005 at 11:21:13AM +0000, Nigel Stephens wrote:

> >>I'd like to force the compiler to store arguments on the stack with 
> >>otherwise optimized code.
> >>
> >>I found a refernce in the archives (form 2001) for using -0 (no 
> >>optimization). Has anyone found another way to do this?
> >
> >
> >If I recall correctly, if you specify -g to enable debugger support,
> >the subroutine prologues store the arguments into their stack slots,
> >even if a higher level of optimization is otherwise specified.
> 
> 
> 'Fraid not: the -g option only adds debug info to the object file, it 
> shouldn't alter the generated code. Using -O0 will certainly store 
> everything on the stack, but it also won't be "with otherwise optimized 
> code".

And the kernel won't build without optimization - but that's FAQ since
10 years.

  Ralf

Re: Saving arguments on the stack

[Ralf Baechle]

On Mon, Nov 21, 2005 at 06:59:20PM -0800, Knittel, Brian wrote:

> I'd like to force the compiler to store arguments on the stack with otherwise optimized code.
> 
> I found a refernce in the archives (form 2001) for using -0 (no optimization). Has anyone found another way to do this?

-O is optimization - same as -O1.

Gcc will save all arguments to the stack for variadic functions (like:
int printf(const char *fmt, ...)) when using somewhat older compiler - I
think before gcc 3.2 or so.  Newer compilers will only save argument
one and up.  Maybe that's good enough?

  Ralf

Re: Saving arguments on the stack

[Maciej W. Rozycki]

On Tue, 22 Nov 2005, Ralf Baechle wrote:

> > 'Fraid not: the -g option only adds debug info to the object file, it 
> > shouldn't alter the generated code. Using -O0 will certainly store 
> > everything on the stack, but it also won't be "with otherwise optimized 
> > code".
> 
> And the kernel won't build without optimization - but that's FAQ since
> 10 years.

 Well, with "__attribute__((always_inline))" available and actually used 
already, perhaps this requirement could be relaxed nowadays...

  Maciej

Re: Saving arguments on the stack

[Ralf Baechle]

On Tue, Nov 22, 2005 at 11:39:28AM +0000, Maciej W. Rozycki wrote:

> > > 'Fraid not: the -g option only adds debug info to the object file, it 
> > > shouldn't alter the generated code. Using -O0 will certainly store 
> > > everything on the stack, but it also won't be "with otherwise optimized 
> > > code".
> > 
> > And the kernel won't build without optimization - but that's FAQ since
> > 10 years.
> 
>  Well, with "__attribute__((always_inline))" available and actually used 
> already, perhaps this requirement could be relaxed nowadays...

There were functions in the network stack that intensionally were
declared extern inline to make sure the compiler won't be able to outline
that function unnoticed.  I just grepped for it and can't find it
anymore, must be a relativly recent improvment.

We also rely on the compiler eleminating calls to certain functions
entirely, for example to __xchg_called_with_bad_pointer().

  Ralf

Re: Saving arguments on the stack

[Dominic Sweetman]

Brian,

> > I'd like to force the compiler to store arguments on the stack
> > with otherwise optimized code.

Sounds like you're out of luck.  Perhaps you'd do better to go one
step back and explain what you're trying to do?

--
Dominic Sweetman
MIPS Technologies

Re: Saving arguments on the stack

[Maciej W. Rozycki]

On Tue, 22 Nov 2005, Ralf Baechle wrote:

> There were functions in the network stack that intensionally were
> declared extern inline to make sure the compiler won't be able to outline
> that function unnoticed.  I just grepped for it and can't find it
> anymore, must be a relativly recent improvment.
> 
> We also rely on the compiler eleminating calls to certain functions
> entirely, for example to __xchg_called_with_bad_pointer().

 Well, that's exactly what "__attribute__((always_inline))" does -- either
inline or fail; the latter AFAIK only happening if the function's body is
unavailable to the current compilation unit.  That happens regardless of 
any optimization settings.

  Maciej

RE: Saving arguments on the stack

[Knittel, Brian]

We'd like to add arguments to the backtrace in Oops messages to make debugging from these reports more efficient. It is particularly useful for determining where the problem was generated, particularly when bad pointers are passed in. This is for production embedded devices with optimized code and which reboot immediately after storing or sending the Oops message. Performance is an issue, but the overhead of storing the arguments on the stack is likely worth the added debug info.
 
Thanks,
--Brian

	-----Original Message----- 
	From: Dominic Sweetman [mailto:dom@mips.com] 
	Sent: Tue 11/22/2005 4:41 AM 
	To: Ralf Baechle 
	Cc: Knittel, Brian; linux-mips@linux-mips.org 
	Subject: Re: Saving arguments on the stack
	
	


	Brian,
	
	> > I'd like to force the compiler to store arguments on the stack
	> > with otherwise optimized code.
	
	Sounds like you're out of luck.  Perhaps you'd do better to go one
	step back and explain what you're trying to do?
	
	--
	Dominic Sweetman
	MIPS Technologies
	
	

RE: Saving arguments on the stack

[Knittel, Brian]

We'd like to add arguments to the backtrace in Oops messages to make debugging from these reports more efficient. It is particularly useful for determining where the problem was generated, particularly when bad pointers are passed in. This is for production embedded devices with optimized code and which reboot immediately after storing or sending the Oops message. Performance is an issue, but the overhead of storing the arguments on the stack is likely worth the added debug info.
 
Thanks,
--Brian

	-----Original Message----- 
	From: Dominic Sweetman [mailto:dom@mips.com] 
	Sent: Tue 11/22/2005 4:41 AM 
	To: Ralf Baechle 
	Cc: Knittel, Brian; linux-mips@linux-mips.org 
	Subject: Re: Saving arguments on the stack
	
	


	Brian,
	
	> > I'd like to force the compiler to store arguments on the stack
	> > with otherwise optimized code.
	
	Sounds like you're out of luck.  Perhaps you'd do better to go one
	step back and explain what you're trying to do?
	
	--
	Dominic Sweetman
	MIPS Technologies
	
	

Re: Saving arguments on the stack

[Ralf Baechle]

On Tue, Nov 22, 2005 at 10:24:09AM -0800, Knittel, Brian wrote:

> We'd like to add arguments to the backtrace in Oops messages to make
> debugging from these reports more efficient. It is particularly useful
> for determining where the problem was generated, particularly when bad
> pointers are passed in. This is for production embedded devices with
> optimized code and which reboot immediately after storing or sending the
> Oops message. Performance is an issue, but the overhead of storing the
> arguments on the stack is likely worth the added debug info.

In this case you would probably have to modify the compiler to save all
arguments.  Another issue is actually finding the stackframe.  For a
debugger using debug information this is possible but short of that it's
hard on MIPS to produce a meaningful backtrace.  Or having something
as complicate as on ia64 ...

  Ralf

RE: Saving arguments on the stack

[Knittel, Brian]

Hi Ralf,
 
I've worked out the backtrace. Changing the compiler is probably not an option. One colleague has suggested that with systems with reasonable size caches, not saving the arguments on the stack does not provide significant performance improvement. I'm sure that depends upon what you are doing, but I suspect he is right for the most part. 
 
Comments, anyone?
 
Thanks,
--Brian

	-----Original Message----- 
	From: Ralf Baechle [mailto:ralf@linux-mips.org] 
	Sent: Wed 11/23/2005 1:54 AM 
	To: Knittel, Brian 
	Cc: linux-mips@linux-mips.org; Dominic Sweetman 
	Subject: Re: Saving arguments on the stack
	
	

	On Tue, Nov 22, 2005 at 10:24:09AM -0800, Knittel, Brian wrote:
	
	> We'd like to add arguments to the backtrace in Oops messages to make
	> debugging from these reports more efficient. It is particularly useful
	> for determining where the problem was generated, particularly when bad
	> pointers are passed in. This is for production embedded devices with
	> optimized code and which reboot immediately after storing or sending the
	> Oops message. Performance is an issue, but the overhead of storing the
	> arguments on the stack is likely worth the added debug info.
	
	In this case you would probably have to modify the compiler to save all
	arguments.  Another issue is actually finding the stackframe.  For a
	debugger using debug information this is possible but short of that it's
	hard on MIPS to produce a meaningful backtrace.  Or having something
	as complicate as on ia64 ...
	
	  Ralf
	

RE: Saving arguments on the stack

[Knittel, Brian]

Hi Ralf,
 
I've worked out the backtrace. Changing the compiler is probably not an option. One colleague has suggested that with systems with reasonable size caches, not saving the arguments on the stack does not provide significant performance improvement. I'm sure that depends upon what you are doing, but I suspect he is right for the most part. 
 
Comments, anyone?
 
Thanks,
--Brian

	-----Original Message----- 
	From: Ralf Baechle [mailto:ralf@linux-mips.org] 
	Sent: Wed 11/23/2005 1:54 AM 
	To: Knittel, Brian 
	Cc: linux-mips@linux-mips.org; Dominic Sweetman 
	Subject: Re: Saving arguments on the stack
	
	

	On Tue, Nov 22, 2005 at 10:24:09AM -0800, Knittel, Brian wrote:
	
	> We'd like to add arguments to the backtrace in Oops messages to make
	> debugging from these reports more efficient. It is particularly useful
	> for determining where the problem was generated, particularly when bad
	> pointers are passed in. This is for production embedded devices with
	> optimized code and which reboot immediately after storing or sending the
	> Oops message. Performance is an issue, but the overhead of storing the
	> arguments on the stack is likely worth the added debug info.
	
	In this case you would probably have to modify the compiler to save all
	arguments.  Another issue is actually finding the stackframe.  For a
	debugger using debug information this is possible but short of that it's
	hard on MIPS to produce a meaningful backtrace.  Or having something
	as complicate as on ia64 ...
	
	  Ralf