Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Backtrace function

Reply
Thread Tools

Backtrace function

 
 
CBFalconer
Guest
Posts: n/a
 
      03-29-2008
Richard Heathfield wrote:
> CBFalconer said:
>> jacob navia wrote:

>
> <snip>
>
>>> fp = GetFramePointer();
>>>
>>> And that is standard C.

>>
>> I think you had better return your C book, and your copy of the C
>> standard, for refunds. Someone has been passing off invalid copies
>> on you.

>
> Consider the following code:
>
> x = y();
>
> Is that standard C? If not, why not?


IMO Not. Because the function y is not detailed. If accompanied
by:

int y(void) {return 123;}

it becomes valid standard C.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
 
Kaz Kylheku
Guest
Posts: n/a
 
      03-29-2008
On Mar 28, 3:40*pm, jacob navia <(E-Mail Removed)> wrote:
> Richard Heathfield wrote:
> > jacob navia said:

>
> >> Kaz Kylheku wrote:
> >>> On Mar 28, 12:47 pm, Keith Thompson <(E-Mail Removed)> wrote:
> >>>> sophia <(E-Mail Removed)> writes:
> >>>>> can any one suggest ways of implementing a backtrace function in ANSI/
> >>>>> standard C as given in the following link ?

>
> >http://pramode.net/2006/09/12/gettin...running-c-code...
> >>>> There's no portable way to do that in standard C.
> >>> Also, there is no nonportable way to do that in standard C, either.

>
> >>>
> >> No, In non portable C you can do it

>
> > You mis-read what he wrote, which is that there is no way (even a
> > non-portable way) to do it in *standard* C.

>
> >> 1) Read the frame pointer (This is the only assembly yo need)

>
> > And Step 1 is where it stops being standard C.

>
> Why?
>
> It means calling
>
> fp = GetFramePointer();
>
> And that is standard C.


I didn't say it couldn't be done with a nonportable program, just that
it couldn't be done with a nonportable standard C program.

A program that calls a function that isn't in standard C, and which
isn't defined in that program, isn't standard C.

It can get through many of the translation phases, but at the point
when it is about to be linked together and executed, there is a
problem. Either the function doesn't exist (unresolved reference), or
it the name resolves to some nonstandard function, which may have any
behavior whatsoever.
 
Reply With Quote
 
 
 
 
Kaz Kylheku
Guest
Posts: n/a
 
      03-29-2008
On Mar 28, 6:18*pm, Richard Heathfield <(E-Mail Removed)> wrote:
> CBFalconer said:
> > I think you had better return your C book, and your copy of the C
> > standard, for refunds. *Someone has been passing off invalid copies
> > on you.

>
> Consider the following code:
>
> * x = y();
>
> Is that standard C? If not, why not?


Not, because you can't have expression statements at file scope, only
declarations.

Next question?
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      03-29-2008
jacob navia wrote, On 28/03/08 23:16:
> Flash Gordon wrote:
>> jacob navia wrote, On 28/03/08 21:39:
>>> Kaz Kylheku wrote:
>>>> On Mar 28, 12:47 pm, Keith Thompson <(E-Mail Removed)> wrote:
>>>>> sophia <(E-Mail Removed)> writes:
>>>>>> can any one suggest ways of implementing a backtrace function in
>>>>>> ANSI/
>>>>>> standard C as given in the following link ?
>>>>>> http://pramode.net/2006/09/12/gettin...running-c-code...
>>>>>>
>>>>> There's no portable way to do that in standard C.
>>>>
>>>> Also, there is no nonportable way to do that in standard C, either.
>>>>
>>>>
>>>
>>> No, In non portable C you can do it

>>
>> Sometimes. Sometimes you can't.
>>
>>> 1) Read the frame pointer (This is the only assembly yo need)

>>
>> If there is one.

>
> Mr "Gordon":
> I said this several lines below. Please read the whole message
> before replying.


You said above that in non-portable C you can do it, this is not always
true.

> I have the feeling that you do not red the message and try to
> understand what I propose but that you jump into each sentence
> trying to find out something to comment negatively on.


No, I read the entire message, and then I pointed out why your statement
that it can be done in non-portable C is not necessarily true.

>>> 2) See at what offset from the frame pointer is the pushed return
>>> address

>>
>> If there is anything to tell you other than the function prologue. Of
>> course the return address might not have been saved to RAM either due
>> to function inlining (as an optimisation) or because it did not need
>> to for some other reason.

>
> The function address is always saved, or, sometimes held in a
> designated register. In both cases it is at a fixed point.


On the TMS320C25 the return address could be in one of two places
depending on whether it is a leaf function or not. If it is a leaf
function the return address will have been left on the HW stack, if not
it will have been popped off the HW stack and pushed on to a stack
structure implemented in SW. How are you going to determine which is the
case? Oh, and library functions might break this rule, and certainly
functions written in assembler can.

So no, it is NOT always held in a fixed point in *real* implementations.

> Obviously, if your function is *inlined* it will NOT appear
> in a backtrace of the stack!
>
> But that is "by design" isn't it?
>
>


It is still a failure to show the C call stack.

>>> 3) The value stored in the saved frame pointer position points to
>>> the next frame.

>>
>> If there is a saved frame pointer. Not all implementations use a
>> separate frame pointer.

>
> See the prerequisites that I wrote below...


Had you said, "It can be done in non-portable C provided that the
following requirements are met" I might not have commented. However, you
started with an incorrect statement that it can be done in non-portable
C (which is not always true).

>>> Here you have the next frame and the address of some point in the
>>> calling procedure.

>>
>> Maybe, if all your assumtions are true so far.
>>
>>> 4) Read the debug information.

>>
>> If there is any which there might not be.

>
> If there is no debug information, a backtrace can still be
> printed, but it is a backrace like:
>
> 0x4477ADD()
> 0x4477665()
>
> etc
>
> The address can be still useful if you have a linker map.


So why not make your statement suitable conditional?

>>> 5) Find out into which function the return address points to.
>>>
>>> 6) Is that the function "main"?
>>>
>>> 7) If not, get the next frame pointer and go to (2)

>>
>> A problem if main was called recursively.

>
> No. As I explained to Mr Heathfield, that raised the same objection,
> my algorithm just stops at the first possible recursive call of main
> It doesn't fail at all. It will not follow recursive calls to "main".
>
> That is all.


Which means it is not correctly reporting the call stack, since the call
stack *includes* the recursive call to main.

> Obviously, calling "main" recurisvely is very popular here.
>
>


Actually, recursive calls to main are an abominations. However they are
allowed.

>>> ---------------
>>>
>>> This supposes that
>>>
>>> (1) you have a frame pointer
>>> (2) The calling function has a frame pointer
>>>

>
> You see?
>
> If you would have read till here, you would have saved yourself
> the remarks above.


So do you accept that it is not always possible despite your claim above?

>>> GDB is written in C, and the lcc-win debugger is
>>> written in C. So there is OBVIOUSLY a way of doing
>>> this in C!

>>
>> No, obviously under some specific circumstances it is possible but it
>> is not always possible or if it is then might be more complex than you
>> have suggested.

>
> Mr "Gordon"
> Writing a debugger is more complex than what I outlined above.
>
> True.
>
> And so what?


So what indeed? We were not talking about writing a debugger.

> The purpose of my algorithm description is not to provide you
> with a ready made debugger implementation!


Good, since that was not the requirement.

> Specially
>
> "Read all debug information" is quite complex as an undertaking,
> I can tell you.


You don't need that for the requirement. However, the requirement is not
generally possible.

Another time your suggestion breaks is if you are in a signal handler
and the signal handlers use a separate stack, which can be the case on
*nix implementations.
--
Flash Gordon
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      03-29-2008
jacob navia wrote, On 28/03/08 23:32:
> Richard Heathfield wrote:
>> jacob navia said:
>>
>>> Flash Gordon wrote:
>>>> jacob navia wrote, On 28/03/08 21:39:

>> <snip>
>>>>> 5) Find out into which function the return address points to.
>>>>>
>>>>> 6) Is that the function "main"?
>>>>>
>>>>> 7) If not, get the next frame pointer and go to (2)
>>>> A problem if main was called recursively.
>>>>
>>> No. As I explained to Mr Heathfield, that raised the same objection,
>>> my algorithm just stops at the first possible recursive call of main
>>> It doesn't fail at all. It will not follow recursive calls to "main".
>>>
>>> That is all.
>>>
>>> Obviously, calling "main" recurisvely is very popular here.

>>
>> Well, not really, but recursive main *is* legal. It seems to me that a
>> non-portable solution would be free to learn main's caller (e.g.
>> _startup, or whatever), and probe for that instead. This would allow
>> recursive main calls to be backtraced properly.


Assuming you can get a backtrace at all, which is not guaranteed.

>> <snip>

>
> In principle you are right, and I considered that. Problem is, my
> startup is obviously not written in C but in assembler... It would
> have been quite impossible to write it in C actually...


With a few extensions you can. At least, I've worked on Pascal
implementations where the startup code was written in Pascal (+
extensions) and this is the same problem.

> In my context, My assembler doesn't know how to emit debug information,
> so there is no debug info.


Then perhaps you should change your assembler so that it does include
the basics. Most assemblers do.

> For startups written in C, your idea would work.


Or for ones written in assembler where the assembler supports debugging.
--
Flash Gordon
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      03-29-2008
CBFalconer said:

> Richard Heathfield wrote:
>> CBFalconer said:
>>> jacob navia wrote:

>>
>> <snip>
>>
>>>> fp = GetFramePointer();
>>>>
>>>> And that is standard C.
>>>
>>> I think you had better return your C book, and your copy of the C
>>> standard, for refunds. Someone has been passing off invalid copies
>>> on you.

>>
>> Consider the following code:
>>
>> x = y();
>>
>> Is that standard C? If not, why not?

>
> IMO Not. Because the function y is not detailed.


Please cite the section of the Standard that requires the source code of a
called function to be present at compilation.


> If accompanied by:
>
> int y(void) {return 123;}
>
> it becomes valid standard C.


So if it were accompanied by int y(void) { return 124; } that would *not*
be standard C? What are the criteria?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      03-29-2008
Kaz Kylheku said:

> On Mar 28, 6:18 pm, Richard Heathfield <(E-Mail Removed)> wrote:
>> CBFalconer said:
>> > I think you had better return your C book, and your copy of the C
>> > standard, for refunds. Someone has been passing off invalid copies
>> > on you.

>>
>> Consider the following code:
>>
>> x = y();
>>
>> Is that standard C? If not, why not?

>
> Not, because you can't have expression statements at file scope, only
> declarations.
>
> Next question?


int main(void)
{
int x;

x = y();

return x;
}



--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Philip Potter
Guest
Posts: n/a
 
      03-29-2008
Richard Heathfield wrote:
> jacob navia said:
>
>> Richard Heathfield wrote:
>>> jacob navia said:
>>>

> <snip>
>
>>>> No, In non portable C you can do it
>>> You mis-read what he wrote, which is that there is no way (even a
>>> non-portable way) to do it in *standard* C.
>>>
>>>> 1) Read the frame pointer (This is the only assembly yo need)
>>> And Step 1 is where it stops being standard C.

>> Why?
>>
>> It means calling
>>
>> fp = GetFramePointer();
>>
>> And that is standard C.

>
> Ha! Yes, we're right on the border here. Clearly, the *call* is standard.
> The implementation of GetFramePointer() is not, *but* the claim was that
> there was no way to do this non-portably in standard C. Standard C
> implementations can legally offer extensions, and non-portable programs
> can take advantage of them whilst remaining syntactically
> standard-conforming. I think you win this round. Nice one.
>
> <snip>
>

I think I may save this message-id for future reference

Phil
 
Reply With Quote
 
Philip Potter
Guest
Posts: n/a
 
      03-29-2008
Richard Heathfield wrote:
> Kaz Kylheku said:
>
>> On Mar 28, 6:18 pm, Richard Heathfield <(E-Mail Removed)> wrote:
>>> CBFalconer said:
>>>> I think you had better return your C book, and your copy of the C
>>>> standard, for refunds. Someone has been passing off invalid copies
>>>> on you.
>>> Consider the following code:
>>>
>>> x = y();
>>>
>>> Is that standard C? If not, why not?

>> Not, because you can't have expression statements at file scope, only
>> declarations.
>>
>> Next question?

>
> int main(void)
> {
> int x;
>
> x = y();
>
> return x;
> }
>
>


Isn't this a constraint violation (in C99 at least)? The identifier y is
undeclared, and is therefore the expression y is not of function pointer
type.

I suggest:

int y(void);

int main(void)
{
int x;
x = y();
return x;
}
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      03-29-2008
Richard Heathfield wrote:
> CBFalconer said:
>> Richard Heathfield wrote:
>>> CBFalconer said:
>>>> jacob navia wrote:
>>>
>>> <snip>
>>>
>>>>> fp = GetFramePointer();
>>>>>
>>>>> And that is standard C.
>>>>
>>>> I think you had better return your C book, and your copy of
>>>> the C standard, for refunds. Someone has been passing off
>>>> invalid copies on you.
>>>
>>> Consider the following code:
>>>
>>> x = y();
>>>
>>> Is that standard C? If not, why not?

>>
>> IMO Not. Because the function y is not detailed.

>
> Please cite the section of the Standard that requires the source
> code of a called function to be present at compilation.


Without that, at some point, the linking step will not function,
and you don't get an executable.

>
>> If accompanied by:
>>
>> int y(void) {return 123;}
>>
>> it becomes valid standard C.

>
> So if it were accompanied by int y(void) { return 124; } that
> would *not* be standard C? What are the criteria?


Existence of valid code for the routine. You are being silly.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
symbol table for backtrace cgable2003@gmail.com C Programming 3 11-26-2007 09:36 PM
Backtrace / crash report on segfault w/o user interaction NeoTrantor C++ 2 03-30-2007 09:23 AM
Getting backtrace on an axception Paolo Pantaleo Python 0 06-10-2006 05:24 PM
backtrace forwarded email's recipients septer2006@hotmail.com Computer Security 0 05-23-2006 03:40 PM
Coredump/backtrace Rafal 'Raf256' Maj C Programming 2 04-12-2005 01:33 PM



Advertisments