From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cjVPFqqaD2cdyQ8AWB0awg (envelope-from ) for ; Wed, 16 Oct 2024 06:51:22 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=BMLTinxa; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 22B291E357; Wed, 16 Oct 2024 06:51:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 7F1251E0C0 for ; Wed, 16 Oct 2024 06:51:20 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0662F385841E for ; Wed, 16 Oct 2024 10:51:20 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id BD4553858D20 for ; Wed, 16 Oct 2024 10:50:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD4553858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BD4553858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1729075858; cv=none; b=exxbOoMdMP3+nJqNCZV8UoY41EmZOV00PaysDkgoNebeHXl9hJjMw07C6NxQuYMdNIv8UAV/Dc/FVxcpuGcDeFSFuslK5dG2T2WJw3Ag/Axwx8nhFdqAVddvD3c0oRDGD18PJCywk+dXG+cmry8bdtx2yTXBAIXPimugKxqXIhk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1729075858; c=relaxed/simple; bh=a5XweehpU3ed3o5/eIhqzO6nItfdoBrCicXbfOUZCiA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=JgsX3qrRKtiinqCX3KT0LGwF4hAt+wDdxXTbV/459wbcsSa7OiyyfgrnZTXQh1W2QOSrkzzPZiJOxag15JDcWCPsnUEuX8zXBnsQN5Ph95j3zoS0aEf5vc1Vz+mdy0oFvRqmi/lYsHKfvxYTq8ux642zu2J7JMAtVCH51MVukYY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729075852; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8PwZ3oFGNb9+ChCaBDgyqHPvxG5ZFnDNRgD6kOfgNzw=; b=BMLTinxa9Zfw+vx4F8gu1gqK3ZDesu5kduSbrH5fkiTZfwniUmI/CHyvd05ZOgANOkcYL2 DtbzPjqmzUM7JEk6auUL8+vPSY14ZoyeIvhRewxdDzjAtqPf2R/jI/Ncek0VrCH/OXfIdp 6KOr0JJ5xz7RDeCPxLi3dd0JrjOvzS4= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-573-pk9xojpWOIaP-1a9FDBgWw-1; Wed, 16 Oct 2024 06:50:51 -0400 X-MC-Unique: pk9xojpWOIaP-1a9FDBgWw-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-43113dab986so56774545e9.2 for ; Wed, 16 Oct 2024 03:50:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729075849; x=1729680649; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:to:from:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=i92KpaYyn7FN/abbRSJkD6cDuTYHM7B3czqoEWYiXic=; b=sEfVlwfNDqowNAoY3f5fhz6vGTiy76UwvZSenfEx7vvHYB4+UFSMjLMkoTImdnMiRx eG35u5q5TSYwaw/M7wCrNm5CCRxn+tWWZoAFd+Gfce5sh96Z9rR5mT775LtJxHBbjoKE H2q4SI/cGUx7Hoti/V06BxQ/yvhqoMA8OXpct0jpRRZaakqC3LyP7mWnvSHbdbf+4Dod cG2J55HO+f6guxyVwm1w9rOzorGA66G2f9n6+P0jhV650gIYbLfnlzneTwnUn4XeIGy1 Qstl5uWbBicSc/CBNbQKmSHcGAKkO52r4wIX5bS6GVq6uBsuW7BQPLfh39qJxtDAvjMi WI2g== X-Forwarded-Encrypted: i=1; AJvYcCXFOFM6DNXHZ5msiR7YY315QPn2aLg+C2Z3vTCvPg09EjQMJowbSauk41PElRg6ziDv5HZOYCez7BF/ZA==@sourceware.org X-Gm-Message-State: AOJu0Ywg+VcL76x7XbMK7ukR7zDn6xnJDGXXA1AQqBOZ4XEopU0RKv87 Ge1OOeac7syYMgSNaYR4SukUFk2OHvVrk5QpjXWBgbJT9l4aduF+VoPASzIurDwfXWxsK84oK8V T305RmHJKqNUiF+2kJ3rxTa+d16bK5ts5oQJHdHSSXXVNYRmySmY2JWv+45I1yVsycE0= X-Received: by 2002:a05:600c:5108:b0:430:9fde:3b92 with SMTP id 5b1f17b1804b1-431255e033bmr173283955e9.14.1729075848874; Wed, 16 Oct 2024 03:50:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGX4FMk1Z/1flcChRGhfDZq7hmHgblcoMr8S+sn1DpWNeZfpNg425qFpGvihQFpUEYxSysccA== X-Received: by 2002:a05:600c:5108:b0:430:9fde:3b92 with SMTP id 5b1f17b1804b1-431255e033bmr173283735e9.14.1729075848388; Wed, 16 Oct 2024 03:50:48 -0700 (PDT) Received: from localhost ([195.213.152.26]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-431503c0214sm18623355e9.29.2024.10.16.03.50.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2024 03:50:47 -0700 (PDT) From: Andrew Burgess To: Guinevere Larsen , gdb-patches@sourceware.org Subject: Re: [PATCH] gdb, configure: Add disable-formats option for configure In-Reply-To: <69c6f0f0-d8b5-4b69-8779-0bcbc3178324@redhat.com> References: <20240925175340.1850969-1-guinevere@redhat.com> <878qv3ylcf.fsf@redhat.com> <69c6f0f0-d8b5-4b69-8779-0bcbc3178324@redhat.com> Date: Wed, 16 Oct 2024 11:50:46 +0100 Message-ID: <87h69c1fuh.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Guinevere Larsen writes: > I managed to reproduce a crash on Linux with a similar setup, but my=20 > backtrace looks a little different. In my version, GDB is trying to=20 > setup solib hooks as a "post start inferior" step, whereas on yours it=20 > seems that GDB is trying to print the location at which the inferior is= =20 > stopped. > > In both cases, though, what happens is that we're calling=20 > find_pc_section, which will try to create a map of sections for quick=20 > lookup, but since we don't understand the file format, GDB thinks we=20 > have no sections (and at least in the linux case, the pointer to the=20 > sections is null). so the issue is not that the offset is -1, but rather= =20 > that this->the_bfd_section is 0x0. > > If I'm correct that this is the cause of the crash on windows as well as= =20 > linux, I think this should fix the crash. Could you sanity check it for m= e? > > > diff --git a/gdb/objfiles.c b/gdb/objfiles.c > index 0e076fe36be..cc8bb253d11 100644 > --- a/gdb/objfiles.c > +++ b/gdb/objfiles.c > @@ -1053,6 +1053,11 @@ update_section_map (struct program_space *pspace, > =C2=A0=C2=A0 gdb_assert (pspace_info->section_map_dirty !=3D 0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 || pspace_info->new_objfiles_available !=3D 0); > > +=C2=A0 /* If there are 0 sections, or the point to the sections is null,= it=20 > makes > +=C2=A0=C2=A0=C2=A0=C2=A0 no sense to try and have a section map at all. = */ > +=C2=A0 if (pspace_info->num_sections =3D=3D 0 || pspace_info->sections = =3D=3D nullptr) > + return; > + > =C2=A0=C2=A0 map =3D *pmap; > =C2=A0=C2=A0 xfree (map); > This does fix the crash in my setup (Windows gdbserver with Linux GDB configured to only support ELF), but I'm not sure this is the approach that I would take. While it is true that this change allows GDB to handle an objfile that is can't otherwise understand, I wonder, how useful is it to even keep the objfile around at all? GDB realises that it can't handle the objfile in find_sym_fns, this is where the "I'm sorry, Dave, I can't do that" message comes from. The backtrace at this point is: #0 find_sym_fns (abfd=3D0x21b4fa0) at ../../src/gdb/symfile.c:1808 #1 0x0000000000c13002 in syms_from_objfile_1 (objfile=3D0x21d3bf0, addrs= =3D0x0, add_flags=3D...) at ../../src/gdb/symfile.c:916 #2 0x0000000000c1330c in syms_from_objfile (objfile=3D0x21d3bf0, addrs= =3D0x0, add_flags=3D...) at ../../src/gdb/symfile.c:998 #3 0x0000000000c13838 in symbol_file_add_with_addrs (abfd=3D..., name=3D= 0x21aeab0 "target:C:/msys64/home/andrew/segv.exe", add_flags=3D..., addrs= =3D0x0, flags=3D..., parent=3D0x0) at ../../src/gdb/symfile.c:1104 #4 0x0000000000c13bd1 in symbol_file_add_from_bfd (abfd=3D..., name=3D0x= 21aeab0 "target:C:/msys64/home/andrew/segv.exe", add_flags=3D..., addrs=3D0= x0, flags=3D..., parent=3D0x0) at ../../src/gdb/symfile.c:1180 #5 0x0000000000c13c20 in symbol_file_add (name=3D0x21aeab0 "target:C:/ms= ys64/home/andrew/segv.exe", add_flags=3D..., addrs=3D0x0, flags=3D...) at .= ./../src/gdb/symfile.c:1193 #6 0x0000000000c13ce6 in symbol_file_add_main_1 (args=3D0x21aeab0 "targe= t:C:/msys64/home/andrew/segv.exe", add_flags=3D..., flags=3D..., reloff=3D0= x0) at ../../src/gdb/symfile.c:1217 #7 0x0000000000c13c8d in symbol_file_add_main (args=3D0x21aeab0 "target:= C:/msys64/home/andrew/segv.exe", add_flags=3D...) at ../../src/gdb/symfile.= c:1208 #8 0x000000000081cfa3 in try_open_exec_file (exec_file_host=3D0x21aeab0 = "target:C:/msys64/home/andrew/segv.exe", inf=3D0x1a1e9f0, add_flags=3D...) = at ../../src/gdb/exec.c:202 #9 0x000000000081d863 in exec_file_locate_attach (pid=3D42000, defer_bp_= reset=3D0, from_tty=3D1) at ../../src/gdb/exec.c:344 The exception thrown in find_sym_fns is not caught until try_open_exec_file. The objfile itself is created in symbol_file_add_with_addrs, and interestingly, if we checkout the end of this function we'll find this line: gdb::observers::new_objfile.notify (objfile); which is going to be completely skipped if we throw an exception as we do in this case. I'm tempted to suggest that what we should consider is removing the objfile if it turns out that GDB doesn't understand it. Attached at the end of this email is a **very** rough patch which does this. After creating the objfile we immediately wrap it in an struct, now if we throw an exception then the objfile is auto-removed from the program space (and deleted). Only if we reach the end of symbol_file_add_with_addrs do we call a method on the local variable to mark the objfile as successfully created. I'd be tempted to convert the `if` checks you added into `gdb_assert` calls, at least initially. I'm not sure if it's possible to have a "valid" objfile that we understand that would otherwise trigger that `if`, hence asserts for now. The patch below is really **very** rough. I'm tempted to think that objfile::make should return the object which auto-removes the objfile, that way anyone who creates an objfile is forced to think about this pattern of creation, validation, accepting... Anyway, would be interested to hear your thoughts. Thanks, Andrew --- diff --git a/gdb/symfile.c b/gdb/symfile.c index 1502fdbe500..17a7be6093b 100644 --- a/gdb/symfile.c +++ b/gdb/symfile.c @@ -854,6 +854,33 @@ init_entry_point_info (struct objfile *objfile) } } =20 +struct scoped_objfile_remover +{ + explicit scoped_objfile_remover (struct objfile *objfile) + : m_objfile (objfile) + { + /* Nothing. */ + } + + ~scoped_objfile_remover () + { + if (m_objfile !=3D nullptr) + { +=09fprintf (stderr, "APB: Removing the objfile, something went wrong\n"); +=09m_objfile->unlink (); + } + } + + void release_objfile () + { + m_objfile =3D nullptr; + } + +private: + + struct objfile *m_objfile; +}; + /* Process a symbol file, as either the main file or as a dynamically loaded file. =20 @@ -1061,6 +1088,7 @@ symbol_file_add_with_addrs (const gdb_bfd_ref_ptr &ab= fd, const char *name, =20 objfile *objfile =3D objfile::make (abfd, current_program_space, name, flags, parent); + scoped_objfile_remover remove_objfile_on_error (objfile); =20 /* We either created a new mapped symbol table, mapped an existing symbol table file which has not had initial symbol reading @@ -1112,6 +1140,9 @@ symbol_file_add_with_addrs (const gdb_bfd_ref_ptr &ab= fd, const char *name, if (objfile->sf !=3D nullptr) finish_new_objfile (objfile, add_flags); =20 + /* No errors. The objfile is officially added. */ + remove_objfile_on_error.release_objfile (); + gdb::observers::new_objfile.notify (objfile); =20 return objfile;