Alternative to __FILE__/__LINE__

Alternative to __FILE__/__LINE__

[François Dumont]

Hi

     Debug mode is using __FILE__/__LINE__ to show where the assertion 
took place. So assertion looks like this:

/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/deque:175:
Error: function requires a valid iterator range [__first, __last).

     But IMHO a smarter information would be to provide the file:line in 
the source code that generated this assertion so that users could more 
easily go to the faulty code.

     So I am looking for __FILE__/__LINE__ equivalents pointing to the 
first non-system source file. Has any such request already be made ? Do 
you think it would worth a request to gcc guys ?

François

Re: Alternative to __FILE__/__LINE__

[Marc Glisse]

On Sun, 4 Mar 2018, François Dumont wrote:

>     Debug mode is using __FILE__/__LINE__ to show where the assertion took 
> place. So assertion looks like this:
>
> /home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/deque:175:
> Error: function requires a valid iterator range [__first, __last).
>
>     But IMHO a smarter information would be to provide the file:line in the 
> source code that generated this assertion so that users could more easily go 
> to the faulty code.

How about printing a backtrace then? Though at some point the user might 
want to start a debugger to get more information.

-- 
Marc Glisse

Re: Alternative to __FILE__/__LINE__

[Petr Ovtchenkov]

On Sun, 4 Mar 2018 21:55:06 +0100 (CET)
Marc Glisse <marc.glisse@inria.fr> wrote:

> On Sun, 4 Mar 2018, François Dumont wrote:
> 
> >     Debug mode is using __FILE__/__LINE__ to show where the assertion took 
> > place. So assertion looks like this:
> >
> > /home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/deque:175:
> > Error: function requires a valid iterator range [__first, __last).
> >
> >     But IMHO a smarter information would be to provide the file:line in the 
> > source code that generated this assertion so that users could more easily go 
> > to the faulty code.
> 
> How about printing a backtrace then? Though at some point the user might 
> want to start a debugger to get more information.
> 

Backtrace will require BFD. BFD may be unavailable or unwanted.

--

  - ptr

Re: Alternative to __FILE__/__LINE__

[François Dumont]

     Yes, backtrace would be even better as long as I can check if I 
have it. I'll look for it.

     A __FILE__/__LINE__ alternative would be simpler but I fear that at 
least __LINE__ would be difficult and/or expensive to get and without it 
something like a __USR_FILE__ macro would be less interesting.

Thanks for your feedback

On 04/03/2018 22:30, Petr Ovtchenkov wrote:
> On Sun, 4 Mar 2018 21:55:06 +0100 (CET)
> Marc Glisse <marc.glisse@inria.fr> wrote:
>
>> On Sun, 4 Mar 2018, François Dumont wrote:
>>
>>>      Debug mode is using __FILE__/__LINE__ to show where the assertion took
>>> place. So assertion looks like this:
>>>
>>> /home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/deque:175:
>>> Error: function requires a valid iterator range [__first, __last).
>>>
>>>      But IMHO a smarter information would be to provide the file:line in the
>>> source code that generated this assertion so that users could more easily go
>>> to the faulty code.
>> How about printing a backtrace then? Though at some point the user might
>> want to start a debugger to get more information.
>>
> Backtrace will require BFD. BFD may be unavailable or unwanted.
>
> --
>
>    - ptr
>

Re: Alternative to __FILE__/__LINE__

[François Dumont]

On 04/03/2018 21:55, Marc Glisse wrote:
> On Sun, 4 Mar 2018, François Dumont wrote:
>
>>     Debug mode is using __FILE__/__LINE__ to show where the assertion 
>> took place. So assertion looks like this:
>>
>> /home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/deque:175: 
>>
>> Error: function requires a valid iterator range [__first, __last).
>>
>>     But IMHO a smarter information would be to provide the file:line 
>> in the source code that generated this assertion so that users could 
>> more easily go to the faulty code.
>
> How about printing a backtrace then? Though at some point the user 
> might want to start a debugger to get more information.
>
I eventually made use of __PRETTY_FUNCTION__ and glibc backtrace 
function which is already used by the profile mode.

With all those additional info debug assertions are much clearer and 
easier to detect in code. For instance:

/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/deque:175:
In function:
     void std::__debug::deque<_Tp, _Allocator>::assign(_InputIterator,
     _InputIterator) [with _InputIterator = const int*;
     <template-parameter-2-2> = void; _Tp = int; _Allocator =
     std::allocator<int>]

Backtrace:
     ./assign1_neg.exe() [0x4046b8]
     ./assign1_neg.exe() [0x400f19]
     /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) 
[0x7fc7a12f3830]
     ./assign1_neg.exe() [0x400f79]

Error: function requires a valid iterator range [__first, __last).

Objects involved in the operation:
     iterator "__first" @ 0x0x7ffd79799140 {
       type = int const* (constant iterator);
     }
     iterator "__last" @ 0x0x7ffd79799148 {
       type = int const* (constant iterator);
     }

And with the help of the addr2line tool you can easily find where faulty 
code it.

I'll commit that once back in stage 1.

François