On Thu, 29 Apr 2021, Bernd Edlinger wrote: > Hi! > > > I've re-based and re-tested this patch on current trunk. > Otherwise the patch is unchanged, from the previous v2 version. > > This patch is fixing two issues with functions where we > do not have proper debug info: > > 1. Functions without line-numbers at all, are excluded from > the CU's address range in the debug info. This makes the > debugger not display any line numbers but instead the debugger > steps into assembler. > > 2. Functions with a declaration line number show this line > number instead of a completely unrelated line-number from a > different function that was emitted before the current one. > > So, since we are again in stage 1: > Is it OK for trunk?
Overall it looks good to me but I'm not familiar with the code and thus maybe unable to spot obvious downsides. So - OK unless you hear concerns by others in a day or two. Thanks, Richard. > > Thanks > Bernd. > > > On 1/13/21 3:59 PM, Bernd Edlinger wrote: > > Hi, > > > > this is a new improved version of my patch. > > The previous patch had two defects: > > It failed with -ffunction-section. Although > > the line info was emitted, that was not working > > since the debug_ranges did not contain the > > thunk. > > And secondly it failed to address the case of > > functions without any source line information. > > > > The new pattch addresses both cases, of DECL_IGNORED_P > > functions: > > > > In the case of virtual thunks we emit the line > > number from the declaration. > > Other than the previous version this patch > > also explicitly adds the virtual thunk to the > > debug_ranges and debug_aranges. If that is not > > done, the debugger does not recognize the line > > table for these functions. > > > > But if that location info is unavailable, > > the function is explicitly removed from the > > debug_ranges and debug_aranges. That has > > the same effect as a theoretical .noloc assembler > > directive. > > > > > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > > Is it OK for trunk? > > > > > > Thanks > > Bernd. > > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)