From: Simon Marchi <simark@simark.ca>
To: Bernd Edlinger <bernd.edlinger@hotmail.de>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCHv2] Fix skip.exp test failure observed with gcc-9.2.0
Date: Tue, 17 Dec 2019 16:12:00 -0000 [thread overview]
Message-ID: <37efc3bf-8775-05a6-14b7-aa327a86b34d@simark.ca> (raw)
In-Reply-To: <AM0PR08MB3714A989DDE06BFDA1F60EABE4500@AM0PR08MB3714.eurprd08.prod.outlook.com>
On 2019-12-17 9:56 a.m., Bernd Edlinger wrote:
> On 12/17/19 3:44 AM, Simon Marchi wrote:
>> On 2019-12-15 1:12 p.m., Bernd Edlinger wrote:
>>> On 12/15/19 2:05 PM, Simon Marchi wrote:
>>>> On 2019-12-15 6:30 a.m., Bernd Edlinger wrote:
>>>>> Hi,
>>>>>
>>>>> this is the split out patch on skip.exp which fixes a pre-existing
>>>>> compatibilty issue with that test case and gcc-9.2.0 (and gcc-10 from
>>>>> trunk of a few weeks ago at least, likely other versions too).
>>>>>
>>>>>
>>>>> Is it OK for trunk?
>>>>>
>>>>>
>>>>> Thanks
>>>>> Bernd.
>>>>>
>>>>>
>>>>
>>>> Hi Bernd,
>>>>
>>>> Just wondering, were you able to figure out which change in debug info lead
>>>> to this behavior change? The behavior with gcc 9.2.0 seems better to be me,
>>>> I think your patch is ok.
>>>>
>>>
>>> Yes indeed. The change started with gcc-8.1.0 when -gcolumn-info was enabled
>>> by default. -gcolumn-info was first implemented in gcc-7.1.0 but default-disabled,
>>> so you can get the altered behavior already with gcc-7 if you manually enable
>>> -gcolumn-info.
>>>
>>> So previously there was just one point where line line 30 (of skip.c) started:
>>>
>>> [0x00000032] Advance Line by 27 to 28
>>> [0x00000034] Copy
>>> [0x00000035] Special opcode 63: advance Address by 4 to 0x4004cb and Line by 2 to 30
>>> [0x00000036] Advance PC by constant 17 to 0x4004dc
>>> [0x00000037] Special opcode 7: advance Address by 0 to 0x4004dc and Line by 2 to 32
>>>
>>> with column-info we have line 30 three times with different column:
>>>
>>> [0x00000034] Advance Line by 27 to 28
>>> [0x00000036] Copy
>>> [0x00000037] Set column to 9
>>> [0x00000039] Special opcode 63: advance Address by 4 to 0x4004c6 and Line by 2 to 30
>>> [0x0000003a] Set column to 17
>>> [0x0000003c] Special opcode 75: advance Address by 5 to 0x4004cb and Line by 0 to 30
>>> [0x0000003d] Set column to 3
>>> [0x0000003f] Special opcode 75: advance Address by 5 to 0x4004d0 and Line by 0 to 30
>>> [0x00000040] Special opcode 105: advance Address by 7 to 0x4004d7 and Line by 2 to 32
>>>
>>>
>>> That could probably be filtered in dwarf2read.c to keep the old behavior, but I agree
>>> that the new behavior makes still sense, even if we cannot really use the column info
>>> in the line number info.
>>
>> That is actually some very good info for anyone wondering why this change was introduced!
>>
>> Could you please put it in the commit message for posterity?
>>
>
> Sure, good point.
>
> Attached is the new, reworded version of the patch.
> When I looked at it again, I stumbled over two wrong comments nearby,
> telling "# Return from foo()" when we actually return from bar(),
> and "# Return from bar()" when we actually return from foo()... :)
>
>>>> I would just remove the unrelated whitespace fix before merging.
>>>>
>>>
>>> Okay, I just replicated you advice regarding 8-space tab columns on
>>> skip-inline.exp in the other patch. Exactly those 2 lines were copied
>>> where the tabs were not used correctly.
>>
>> Great thanks. Note that we can also fix skip.exp, just in another, obvious patch.
>>
>
> Okay, will send a separate patch for the whitespace.
>
>
> Thanks
> Bernd.
>
Thanks, I pushed it.
Simon
prev parent reply other threads:[~2019-12-17 16:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AM0PR08MB3714A919F6C50D7EEB19C302E4560@AM0PR08MB3714.eurprd08.prod.outlook.com>
2019-12-15 11:30 ` [PATCH] " Bernd Edlinger
2019-12-15 13:05 ` Simon Marchi
2019-12-15 18:12 ` Bernd Edlinger
2019-12-17 2:44 ` Simon Marchi
2019-12-17 14:56 ` [PATCHv2] " Bernd Edlinger
2019-12-17 16:12 ` Simon Marchi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37efc3bf-8775-05a6-14b7-aa327a86b34d@simark.ca \
--to=simark@simark.ca \
--cc=bernd.edlinger@hotmail.de \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox