On Wed, 6 Jan 2021, Jakub Jelinek wrote:
> On Wed, Jan 06, 2021 at 08:50:43AM +0100, Richard Biener wrote:
> > > Theoretically we could exclude the range of the no-loc function
> > > from the .debug_ranges, then gdb would not even step into the function.
> >
> > I'd argue we're failing to emit a
On 1/6/21 12:49 PM, Eric Botcazou wrote:
>> currently there is a problem when debugging a virtual thunk. That is
>> a decl with DECL_IGNORED_P. Currently the line information displayed
>> in gdb is completely bogus, thus the last line of whatever function
>> is immediately before the PC of the th
> currently there is a problem when debugging a virtual thunk. That is
> a decl with DECL_IGNORED_P. Currently the line information displayed
> in gdb is completely bogus, thus the last line of whatever function
> is immediately before the PC of the thunk.
DECL_IGNORED_P means completely ignored
On Wed, Jan 06, 2021 at 08:50:43AM +0100, Richard Biener wrote:
> > Theoretically we could exclude the range of the no-loc function
> > from the .debug_ranges, then gdb would not even step into the function.
>
> I'd argue we're failing to emit a .endloc at the end of functions
> (rather than issue
On 1/4/21 10:45 PM, Jeff Law wrote:
>
>
> On 1/4/21 1:06 PM, Bernd Edlinger wrote:
>> --- a/gcc/final.c
>> +++ b/gcc/final.c
>> @@ -1735,7 +1735,12 @@ final_start_function_1 (rtx_insn **firstp, FILE
>> *file, int *seen,
>> last_filename);
>>
>>if (!dwarf2_d
On Wed, 6 Jan 2021, Bernd Edlinger wrote:
> On 1/6/21 8:01 AM, Alexandre Oliva wrote:
> > On Jan 5, 2021, Richard Biener wrote:
> >
> >> But isn't this a consumer issue then? If there is no line info for
> >> a PC range then gdb shouldn't display any.
> >
> > No, there *is* line info there, c
On 1/6/21 8:01 AM, Alexandre Oliva wrote:
> On Jan 5, 2021, Richard Biener wrote:
>
>> But isn't this a consumer issue then? If there is no line info for
>> a PC range then gdb shouldn't display any.
>
> No, there *is* line info there, carried over from an earlier .loc
> directive, as there is
On Jan 5, 2021, Richard Biener wrote:
> But isn't this a consumer issue then? If there is no line info for
> a PC range then gdb shouldn't display any.
No, there *is* line info there, carried over from an earlier .loc
directive, as there isn't anything like ".noloc" to output with a
function t
On Jan 4, 2021, Bernd Edlinger wrote:
> currently there is a problem when debugging a virtual thunk. That is
> a decl with DECL_IGNORED_P. Currently the line information displayed
> in gdb is completely bogus, thus the last line of whatever function
> is immediately before the PC of the thunk.
On Mon, 4 Jan 2021, Bernd Edlinger wrote:
> Hi,
>
>
> currently there is a problem when debugging a virtual thunk. That is
> a decl with DECL_IGNORED_P. Currently the line information displayed
> in gdb is completely bogus, thus the last line of whatever function
> is immediately before the PC
On 1/4/21 1:06 PM, Bernd Edlinger wrote:
> Hi,
>
>
> currently there is a problem when debugging a virtual thunk. That is
> a decl with DECL_IGNORED_P. Currently the line information displayed
> in gdb is completely bogus, thus the last line of whatever function
> is immediately before the PC
Hi,
currently there is a problem when debugging a virtual thunk. That is
a decl with DECL_IGNORED_P. Currently the line information displayed
in gdb is completely bogus, thus the last line of whatever function
is immediately before the PC of the thunk.
This patch improves the debug experience
12 matches
Mail list logo
