public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Andrew Burgess <aburgess@redhat.com>, gdb-patches@sourceware.org
Cc: Eli Zaretskii <eliz@gnu.org>, Tom Tromey <tom@tromey.com>
Subject: Re: [PATCHv3] gdb: add Python events for program space addition and removal
Date: Mon, 2 Oct 2023 14:34:27 -0400	[thread overview]
Message-ID: <18e22709-5bec-4175-a057-09ee92415a46@simark.ca> (raw)
In-Reply-To: <72cbc08125523c408306fca80317b9e7fad6e82e.1695993752.git.aburgess@redhat.com>

On 9/29/23 09:24, Andrew Burgess via Gdb-patches wrote:
> In v3:
> 
>   - Rebased onto current master (there were some conflicts),
> 
>   - No other changes.
> 
> Code is already approved, just needs a doc review.
> 
> Thanks,
> Andrew
> 
> 
> ---
> 
> Initially I just wanted a Python event for when GDB removes a program
> space, I'm writing a Python extension that caches information for each
> program space, and need to know when I should discard entries for a
> particular program space.
> 
> But, it seemed easy enough to also add an event for when GDB adds a
> new program space, so I went ahead and added both new events.
> 
> Of course, we don't currently have an observable for program space
> addition or removal, so I first needed to add these.  After that it's
> pretty simple to add two new Python events and have these trigger.
> 
> The two new event registries are:
> 
>   events.new_progspace
>   events.free_progspace
> 
> These emit NewProgspaceEvent and FreeProgspaceEvent objects
> respectively, each of these new event types has a 'progspace'
> attribute that contains the relevant gdb.Progspace object.
> 
> There's a couple of things to be mindful of.
> 
> First, it is not possible to catch the NewProgspaceEvent for the very
> first program space, the one that is created when GDB first starts, as
> this program space is created before any Python scripts are sourced.
> 
> In order to allow this event to be caught we would need to defer
> creating the first program space, and as a consequence the first
> inferior, until some later time.  But, existing scripts could easily
> depend on there being an initial inferior, so I really don't think we
> should change that -- and so, we end up with the consequence that we
> can't catch the event for the first program space.
> 
> The second, I think minor, issue, is that GDB doesn't clean up its
> program spaces upon exit -- or at least, they are not cleaned up
> before Python is shut down.  As a result, any program spaces in use at
> the time GDB exits don't generate a FreeProgspaceEvent.  I'm not
> particularly worried about this for my use case, I'm using the event
> to ensure that a cache doesn't hold stale entries within a single GDB
> session.  It's also easy enough to add a Python at-exit callback which
> can do any final cleanup if needed.
> 
> Finally, when testing, I did hit a slightly weird issue with some of
> the remote boards (e.g. remote-stdio-gdbserver).  As a consequence of
> this issue I see some output like this in the gdb.log:
> 
>   (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
>   step
>   FreeProgspaceEvent: <gdb.Progspace object at 0x7fb7e1d19c10>
>   warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running.
>   Use the "interrupt" command to stop the target
>   and then try again.
>   warning: cannot close "target:/lib64/libc.so.6": Cannot execute this command while the target is running.
>   Use the "interrupt" command to stop the target
>   and then try again.
>   warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Cannot execute this command while the target is running.
>   Use the "interrupt" command to stop the target
>   and then try again.
>   do_parent_stuff () at py-progspace-events.c:41
>   41        ++global_var;
>   (gdb) PASS: gdb.python/py-progspace-events.exp: step
> 
> The 'FreeProgspaceEvent ...' line is expected, that's my test Python
> extension logging the event.  What isn't expected are all the blocks
> like:
> 
>   warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running.
>   Use the "interrupt" command to stop the target
>   and then try again.
> 
> It turns out that this has nothing to do with my changes, this is just
> a consequence of reading files over the remote protocol.  The test
> forks a child process which GDB stays attached too.  When the child
> exits, GDB cleans up by calling prune_inferiors, which in turn can
> result in GDB trying to close some files that are open because of the
> inferior being deleted.
> 
> If the prune_inferiors call occurs when the remote target is
> running (and in non-async mode) then GDB will try to send a fileio
> packet while the remote target is waiting for a stop reply, and the
> remote target will throw an error, see remote_target::putpkt_binary in
> remote.c for details.
> 
> I'm going to look at fixing this, but, as I said, this is nothing to
> do with this change, I just mention it because I ended up needing to
> account for these warning messages in one of my tests, and it all
> looks a bit weird.
> 
> Approved-By: Tom Tromey <tom@tromey.com>

Hi Andrew,

The new test fails with native-gdbserver:


    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.python/py-progspace-events.exp ...
    ERROR: GDB process no longer exists

    # of expected passes            9
    # of unresolved testcases       4

GDB aborts when calling error here, apparently nothing catches the
exception so std::terminate is called:

    #4  0x000055a4a0fae18d in error (fmt=0x55a49adcd020 "Cannot execute this command while the target is running.\nUse the \"interrupt\" command to stop the target\nand then try again.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:46
    #5  0x000055a49ec2f495 in remote_target::putpkt_binary (this=0x61b00003f080, buf=0x62d00371e400 "qXfer:auxv:read::0,1000", cnt=23) at /home/smarchi/src/binutils-gdb/gdb/remote.c:9740
    #6  0x000055a49ec2efc4 in remote_target::putpkt (this=0x61b00003f080, buf=0x62d00371e400 "qXfer:auxv:read::0,1000") at /home/smarchi/src/binutils-gdb/gdb/remote.c:9698
    #7  0x000055a49ec8b287 in remote_target::putpkt (this=0x61b00003f080, buf=std::__debug::vector of length 36862, capacity 36862 = {...}) at /home/smarchi/src/binutils-gdb/gdb/remote.c:1211
    #8  0x000055a49ec45c59 in remote_target::remote_read_qxfer (this=0x61b00003f080, object_name=0x55a49adced00 "auxv", annex=0x0, readbuf=0x62100057f900 '\276' <repeats 200 times>..., offset=0, len=3904966623561266976, xfered_len=0x7f5f31c5f220, which_packet=18) at /home/smarchi/src/binutils-gdb/gdb/remote.c:11316
    #9  0x000055a49ec47573 in remote_target::xfer_partial (this=0x61b00003f080, object=TARGET_OBJECT_AUXV, annex=0x0, readbuf=0x62100057f900 '\276' <repeats 200 times>..., writebuf=0x0, offset=0, len=4096, xfered_len=0x7f5f31c5f220) at /home/smarchi/src/binutils-gdb/gdb/remote.c:11438
    #10 0x000055a49f4595b1 in target_xfer_partial (ops=0x61b00003f080, object=TARGET_OBJECT_AUXV, annex=0x0, readbuf=0x62100057f900 '\276' <repeats 200 times>..., writebuf=0x0, offset=0, len=4096, xfered_len=0x7f5f31c5f220) at /home/smarchi/src/binutils-gdb/gdb/target.c:1717
    #11 0x000055a49f45aed9 in target_read_partial (ops=0x61b00003f080, object=TARGET_OBJECT_AUXV, annex=0x0, buf=0x62100057f900 '\276' <repeats 200 times>..., offset=0, len=4096, xfered_len=0x7f5f31c5f220) at /home/smarchi/src/binutils-gdb/gdb/target.c:1951
    #12 0x000055a49f501472 in target_read_alloc_1<unsigned char> (ops=0x61b00003f080, object=TARGET_OBJECT_AUXV, annex=0x0) at /home/smarchi/src/binutils-gdb/gdb/target.c:2286
    #13 0x000055a49f45c9c2 in target_read_alloc (ops=0x61b00003f080, object=TARGET_OBJECT_AUXV, annex=0x0) at /home/smarchi/src/binutils-gdb/gdb/target.c:2315
    #14 0x000055a49c920733 in target_read_auxv_raw (ops=0x61b00003f080) at /home/smarchi/src/binutils-gdb/gdb/auxv.c:379
    #15 0x000055a49c920501 in target_read_auxv () at /home/smarchi/src/binutils-gdb/gdb/auxv.c:368
    #16 0x000055a49c920c06 in target_auxv_search (match=0, valp=0x7f5f31a2fc60) at /home/smarchi/src/binutils-gdb/gdb/auxv.c:415
    #17 0x000055a49e13e669 in linux_is_uclinux () at /home/smarchi/src/binutils-gdb/gdb/linux-tdep.c:433
    #18 0x000055a49e13e6fa in linux_has_shared_address_space (gdbarch=0x61c00001e080) at /home/smarchi/src/binutils-gdb/gdb/linux-tdep.c:440
    #19 0x000055a49c720d6f in gdbarch_has_shared_address_space (gdbarch=0x61c00001e080) at /home/smarchi/src/binutils-gdb/gdb/gdbarch.c:4889
    #20 0x000055a49e7ce076 in program_space::~program_space (this=0x61300004af00, __in_chrg=<optimized out>) at /home/smarchi/src/binutils-gdb/gdb/progspace.c:124
    #21 0x000055a49de5d91e in delete_inferior (inf=0x61800007f080) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:290
    #22 0x000055a49de604b7 in prune_inferiors () at /home/smarchi/src/binutils-gdb/gdb/inferior.c:480
    #23 0x000055a49debd2d9 in fetch_inferior_event () at /home/smarchi/src/binutils-gdb/gdb/infrun.c:4558

Simon

  parent reply	other threads:[~2023-10-02 18:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-21 12:44 [PATCH] " Andrew Burgess
2023-09-21 19:20 ` Tom Tromey
2023-09-27 10:51   ` Andrew Burgess
2023-09-27 14:20     ` Tom Tromey
2023-09-27 15:17       ` Andrew Burgess
2023-09-27 15:16 ` [PATCHv2] " Andrew Burgess
2023-09-29 12:41   ` Eli Zaretskii
2023-09-29 13:24   ` [PATCHv3] " Andrew Burgess
2023-09-29 15:46     ` Eli Zaretskii
2023-10-02 16:09       ` Andrew Burgess
2023-10-02 18:34     ` Simon Marchi [this message]
2023-10-02 20:36       ` Andrew Burgess
2023-10-02 20:38         ` Simon Marchi
2023-10-02 21:17           ` Andrew Burgess
2023-10-02 20:11     ` [PUSHED] gdb/python: reformat file with black Andrew Burgess

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=18e22709-5bec-4175-a057-09ee92415a46@simark.ca \
    --to=simark@simark.ca \
    --cc=aburgess@redhat.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).