On Oct 16, 2019, Luis Machado wrote:
> It seems, from reading the blog post about SFN's, that it was meant to
> help with debugging optimized binaries.
Indeed. Getting rid of the dummy jumps would be one kind of
optimization, and then SFN might help preserve some of the loss of
location info
On Wed, Oct 16, 2019 at 4:55 PM Luis Machado wrote:
>
> On 10/16/19 5:59 AM, Richard Biener wrote:
> > I think that adding an extra jump is unwanted. Instead - if you disregard
> > the single-source-line case - there's always the jump and the label we jump
> > to which might/should get different
On 10/16/19 11:17 AM, Luis Machado wrote:
Hi Maciej,
On 10/16/19 11:11 AM, Maciej W. Rozycki wrote:
Hi Luis,
Is there a better way to force the compiler to output such a line table
transition without having to resort to a dummy jump? Is there a safer
way to add such transitions without
On 10/16/19 5:59 AM, Richard Biener wrote:
I think that adding an extra jump is unwanted. Instead - if you disregard
the single-source-line case - there's always the jump and the label we jump
to which might/should get different source locations. Like in one of the above
cases:
main ()
{
Hi Maciej,
On 10/16/19 11:11 AM, Maciej W. Rozycki wrote:
Hi Luis,
Is there a better way to force the compiler to output such a line table
transition without having to resort to a dummy jump? Is there a safer
way to add such transitions without worrying about the optimizer getting
rid of them
Hi Luis,
> Is there a better way to force the compiler to output such a line table
> transition without having to resort to a dummy jump? Is there a safer
> way to add such transitions without worrying about the optimizer getting
> rid of them later on? Should we even worry about preserving
On Tue, Oct 15, 2019 at 9:58 PM Luis Machado wrote:
>
> Hi,
>
> I'd like to get some feedback from the compiler's side before
> implementing a fix for this line numbering problem. I also want to make
> sure i fix it in the right tool.
>
> This is related to this bug report in GDB's bugzilla:
>
