Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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

  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