On 2009-04-03 19:24:25 +0200, Christopher Wright <dhasenan@gmail.com> said:

> Georg Wrede wrote:
>> Fawzi Mohamed wrote:
>>> Well inlined functions will have no frame, also last call optimization (tail optimization) removes the frame.
>> 
>> If I were to write a compiler, then using "-g -debug", etc. would make sure neither happens!
> 
> However, closures in D1 have a stack frame that is within the creating function's stack frame, and gdb assumes that means a corrupt stack. There's no real way around this.

Now this is more clear, thanks!

On 2009-04-03 10:33:19 +0200, Walter Bright <newshound1@digitalmars.com> said:

> Fawzi Mohamed wrote:
>> you are right, on mac with dmd I get the full trace, on linux not. About the missing line and file information I think dmd does not add that on mac/linux.
> 
> You can see using dumpobj -p on the object files that dmd *does* put in the information.

then the correct statement is that libbdf is not able to interpret that information correctly, because both on mac and on linux gdb and addr2line are not able to use it

Fawzi Mohamed wrote:
> then the correct statement is that libbdf is not able to interpret that information correctly, because both on mac and on linux gdb and addr2line are not able to use it


Right. I just don't know what is wrong with it. It appears to be correct according to the dwarf spec.

Fawzi Mohamed wrote:
> On 2009-04-02 21:18:55 +0200, Sean Kelly <sean@invisibleduck.org> said:
> 
>> == Quote from Georg Wrede (georg.wrede@iki.fi)'s article
>>> Fawzi Mohamed wrote:
>>>>
>>>> The tracing of tango svn version (that uses libc backtrace) seems to
>>>> work rather well.
>>>> It does not give you the names, but as said that is due to a license
>>>> problem.
>>> Aarrghhh. What most frustrates me is when something obvious can't be done because of external trivialities.
>>
>> The Tango plugin architecture for backtrace was designed so that the
>> backtrace code doesn't have to be integrated into Tango itself,
>> eliminating
>> the license problem.  But I can see how this might be a problem if you
>> want to bundle a backtrace library with Tango :-)
> 
> having some stacktracing by default there was the number one request at
> the tango reference, and also in the wish list for a while.
> The idea is not to disallow external solutions, but to have something
> working there by default.
> Please note that something using GPL code even as plugin forces the
> whole application to be GPL, which is not acceptable for anyone not
> wanting to release its application as GPL.
> 
	The glibc has functions for stack tracing (backtrace and
backtrace_symbols) and it's licensed under the LGPL, so there should
be no problem...

		Jerome
- --
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Fawzi Mohamed wrote:
> On 2009-04-03 19:24:25 +0200, Christopher Wright <dhasenan@gmail.com> said:
> 
>> Georg Wrede wrote:
>>> Fawzi Mohamed wrote:
>>>> Well inlined functions will have no frame, also last call optimization (tail optimization) removes the frame.
>>>
>>> If I were to write a compiler, then using "-g -debug", etc. would make sure neither happens!
>>
>> However, closures in D1 have a stack frame that is within the creating function's stack frame, and gdb assumes that means a corrupt stack. There's no real way around this.
> 
> Now this is more clear, thanks!

If the current D closure architecture is considered stable and permanent, then maybe the gdb or glibc folks might want to look at it?

And while at it, they'd probably know right off the bat what seems to be the problem with D stack traces not currently showing properly.