Prev: Ada Debian policy plea
Next: info version of Ada reference manuals
From: Simon Wright on 23 May 2010 15:46
"(see below)" <yaldnif.w(a)blueyonder.co.uk> writes:

> Are these features enabled in your OS X port, Simon?

That was a prerelease 4.5.0 -- presently running with my build of the
official GCC release.

So far as I know, these features are the same.. yes, just tried it.

The tracebacks you get with atos are rather opaque, and the tool is too
stupid to work out the architecture for itself ..

$ atos -o t -arch x86_64 0x100001577 0x10000141b
_ada_t (in t) (t.adb:16)
main (in t) (b~t.adb:196)
$ atos -o t -arch x86_64 0x100001742 0x10000aa82 0x7fff825fb8b4
t__tTKB.2815 (in t) + 86
system__tasking__stages__task_wrapper (in t) + 418
0x7fff825fb8b4
From: Stephen Leake on 24 May 2010 05:03
Stephen Leake <stephen_leake(a)stephe-leake.org> writes:

> Simon Wright <simon(a)pushface.org> writes:
>
>> "(see below)" <yaldnif.w(a)blueyonder.co.uk> writes:
>>
>>> On 21/05/2010 09:52, in article 82bpc8s17m.fsf(a)stephe-leake.org, "Stephen
>>> Leake" <stephen_leake(a)stephe-leake.org> wrote:
>>
>>>> Because symbolic traceback are not supported on _all_ gnat platforms, I
>>>> don't use them on _any_ - that way my code is portable. So I did not
>>>> notice this problem.
>>>>
>>>> I dump the stack trace as hex addresses, then later run addr2line
>>>> manually if I want the symbolic trace.
>>>
>>> Can you say exactly what the steps are to do that?
>>> I've never understood it + therefore never used it.
>>
>> You need to call
>>
>> GNAT.Exception_Traces.Trace_On
>> (Kind => GNAT.Exception_Traces.Unhandled_Raise);
>
> I never do this.
>
>> from somewhere in your program and run gnatmake with -bargs -E.
>
> I only do this if I want symbolic traces from the running program, which
> I don't anymore.

Sorry, I was mistaken; -bars -E is required for numeric tracebacks. It's
been too long since I looked at the contents of my standard gpr file.

--
-- Stephe
From: Stephen Leake on 24 May 2010 05:04
Simon Wright <simon(a)pushface.org> writes:

> "(see below)" <yaldnif.w(a)blueyonder.co.uk> writes:
>
>> Are these features enabled in your OS X port, Simon?
>
> That was a prerelease 4.5.0 -- presently running with my build of the
> official GCC release.
>
> So far as I know, these features are the same.. yes, just tried it.
>
> The tracebacks you get with atos are rather opaque, and the tool is too
> stupid to work out the architecture for itself ..
>
> $ atos -o t -arch x86_64 0x100001577 0x10000141b
> _ada_t (in t) (t.adb:16)
> main (in t) (b~t.adb:196)

Good enough for emacs to find and display the source location, which is
all you really need.

--
-- Stephe
From: Simon Wright on 24 May 2010 15:14
Stephen Leake <stephen_leake(a)stephe-leake.org> writes:

> Simon Wright <simon(a)pushface.org> writes:
>
>> "(see below)" <yaldnif.w(a)blueyonder.co.uk> writes:
>>
>>> Are these features enabled in your OS X port, Simon?
>>
>> That was a prerelease 4.5.0 -- presently running with my build of the
>> official GCC release.
>>
>> So far as I know, these features are the same.. yes, just tried it.
>>
>> The tracebacks you get with atos are rather opaque, and the tool is too
>> stupid to work out the architecture for itself ..
>>
>> $ atos -o t -arch x86_64 0x100001577 0x10000141b
>> _ada_t (in t) (t.adb:16)
>> main (in t) (b~t.adb:196)
>
> Good enough for emacs to find and display the source location, which is
> all you really need.

I agree about that one, but the next (from the task which died with an
unhandled exception) was

$ atos -o t -arch x86_64 0x100001742 0x10000aa82 0x7fff825fb8b4
t__tTKB.2815 (in t) + 86
system__tasking__stages__task_wrapper (in t) + 418
0x7fff825fb8b4

I dare say a less trivia example would work better.
From: Stephen Leake on 24 May 2010 22:13
Simon Wright <simon(a)pushface.org> writes:

> Stephen Leake <stephen_leake(a)stephe-leake.org> writes:
>
>> Simon Wright <simon(a)pushface.org> writes:
>>
>>> "(see below)" <yaldnif.w(a)blueyonder.co.uk> writes:
>>>
>>>> Are these features enabled in your OS X port, Simon?
>>>
>>> That was a prerelease 4.5.0 -- presently running with my build of the
>>> official GCC release.
>>>
>>> So far as I know, these features are the same.. yes, just tried it.
>>>
>>> The tracebacks you get with atos are rather opaque, and the tool is too
>>> stupid to work out the architecture for itself ..
>>>
>>> $ atos -o t -arch x86_64 0x100001577 0x10000141b
>>> _ada_t (in t) (t.adb:16)
>>> main (in t) (b~t.adb:196)
>>
>> Good enough for emacs to find and display the source location, which is
>> all you really need.
>
> I agree about that one, but the next (from the task which died with an
> unhandled exception) was
>
> $ atos -o t -arch x86_64 0x100001742 0x10000aa82 0x7fff825fb8b4
> t__tTKB.2815 (in t) + 86
> system__tasking__stages__task_wrapper (in t) + 418
> 0x7fff825fb8b4
>
> I dare say a less trivia example would work better.

I often find the stack trace from a multitasking program to be pretty
useless. The real problem is in some inner task, but the stack trace you
get is from the environment task.

That's when you have to write code to have each task dump its own stack
when it dies.

And on the gripping hand, stack traces from fully optimized code are
also often useless.

--
-- Stephe
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Ada Debian policy plea
Next: info version of Ada reference manuals