From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
To: "Willgerodt, Felix" <felix.willgerodt@intel.com>,
Tom Tromey <tom@tromey.com>,
Felix Willgerodt via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 1/2] gdb: Allow address space qualifier parsing in C++.
Date: Fri, 2 Apr 2021 12:51:24 -0400 [thread overview]
Message-ID: <9fb100c8-7c2b-8270-39b4-fb007110d55b@polymtl.ca> (raw)
In-Reply-To: <f957abd6-f83e-369d-7337-c6a4f4c9f5e1@polymtl.ca>
On 2021-04-02 12:48 p.m., Simon Marchi via Gdb-patches wrote:>> This '@address_space_qualifier' is a bit of an undocumented and untested feature AFAIK. Even the avr tests for __flash don't test it.
>> I did search the git history a bit, but couldn't really determine why it was added. Only that it was added years before the __flash patch was.
>> But since it is there and since I need a language agnostic way to specify this, I plan to use it for a future target.
>>
>> The only test I could currently write for this patch is something like:
>> gdb_test "*(@somerandomqualifiername int *) 0x12345678" "Unknown address space specifier: \"somerandomqualifiername\"">
>> for a C++ program on any target. If you think that is valuable, I can easily add that.
>> The target I want to use this for in the end won't be ready for upstream for a while unfortunately.
>
> Hi Felix,
>
> I think it would be valuable to have a test like this. It's better
> than nothing, and it's always good to check error cases to make sure GDB
> doesn't crash on them. I can imagine that this test could test with
> both a C and C++ program to cover everything correctly (and maybe other
> languages, but I don't know much about them, if that even applies to
> them).
>
> A while ago I added a simavr board file, to be able to run tests against
> an AVR target. simavr is easy to build and use (it may even be packaged
> in distros, but I'd be tempted to use the latest available version).
> All of this to say you could try to run and improve the flash qualifier
> test for AVR (or write a new test).
>
> There's just one thing, avr-gcc/avr-g++ seem to produce stabs by
> default, it's not really useful to test with stabs nowadays. I had a
> patch to make that board use dwarf by default (see below), but I never
> got around to try it properly and post it. I'll try to do it soon (but
> you can apply it locally in the mean time).
>
> Simon
Oh, and when running the test (with the dwarf patch applied), I hit an
internal error:
92 (gdb) PASS: gdb.arch/avr-flash-qualifier.exp: print p
93 backtrace 1^M
94 #0 pass_to_function (p=0xe4 <data_in_flash> "\253") at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.arch/avr-flash-qualifier.c:23^M
95 /home/simark/src/binutils-gdb/gdb/trad-frame.h:143: internal-error: LONGEST trad_frame_saved_reg::addr() const: Assertion `m_kind == trad_frame_saved_reg_ kind::ADDR' failed.^M
I'll try to bisect that, it might be a problem introduced by the
recent trad_frame changes (or the changes merely uncovered an existing
bug).
Simon
next prev parent reply other threads:[~2021-04-02 16:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-26 14:26 [PATCH 0/2] Expression parser fixes for address space qualifiers Felix Willgerodt via Gdb-patches
2021-03-26 14:26 ` [PATCH 1/2] gdb: Allow address space qualifier parsing in C++ Felix Willgerodt via Gdb-patches
2021-04-01 18:16 ` Tom Tromey
2021-04-02 12:33 ` Willgerodt, Felix via Gdb-patches
2021-04-02 12:47 ` Luis Machado via Gdb-patches
2021-04-02 16:48 ` Simon Marchi via Gdb-patches
2021-04-02 16:51 ` Simon Marchi via Gdb-patches [this message]
2021-04-05 2:32 ` Simon Marchi via Gdb-patches
2021-04-06 9:30 ` Willgerodt, Felix via Gdb-patches
2021-03-26 14:26 ` [PATCH 2/2] gdb: Fix reduce/reduce conflicts for qualifier_seq_noopt in the C parser Felix Willgerodt via Gdb-patches
2021-04-01 18:20 ` Tom Tromey
2021-04-02 12:33 ` Willgerodt, Felix via Gdb-patches
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=9fb100c8-7c2b-8270-39b4-fb007110d55b@polymtl.ca \
--to=gdb-patches@sourceware.org \
--cc=felix.willgerodt@intel.com \
--cc=simon.marchi@polymtl.ca \
--cc=tom@tromey.com \
/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