From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20358 invoked by alias); 6 Jun 2009 00:27:17 -0000 Received: (qmail 20346 invoked by uid 22791); 6 Jun 2009 00:27:16 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 06 Jun 2009 00:27:08 +0000 Received: (qmail 6025 invoked from network); 6 Jun 2009 00:27:06 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Jun 2009 00:27:06 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: corelow and threads question Date: Sat, 06 Jun 2009 00:27:00 -0000 User-Agent: KMail/1.9.10 Cc: Aleksandar Ristovski References: <200906052025.10264.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906060127.57034.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00058.txt.bz2 On Friday 05 June 2009 20:40:23, Aleksandar Ristovski wrote: > +static LONGEST > +nto_core_xfer_partial (struct target_ops *ops, enum target_object object, > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 const char *an= nex, gdb_byte *readbuf, > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 const gdb_byte= *writebuf, ULONGEST offset, LONGEST len) > +{ > + =A0if (object =3D=3D TARGET_OBJECT_AUXV > + =A0 =A0 =A0&& readbuf) > + =A0 =A0{ > + =A0 =A0 =A0struct auxv_buf auxv_buf; > + > + =A0 =A0 =A0auxv_buf.len =3D len; > + =A0 =A0 =A0auxv_buf.len_read =3D 0; > + =A0 =A0 =A0auxv_buf.readbuf =3D readbuf; > + =A0 =A0 =A0 > + =A0 =A0 =A0if (offset > 0) > +=A0=A0=A0=A0=A0=A0=A0return 0; > + > + =A0 =A0 =A0bfd_map_over_sections (core_bfd, nto_core_read_auxv_from_not= e, &auxv_buf); > + =A0 =A0 =A0if (auxv_buf.len_read > 0) > +=A0=A0=A0=A0=A0=A0=A0return auxv_buf.len_read; > + =A0 =A0} > + > + =A0/* In any other case, try default code. =A0*/ > + =A0return original_core_ops.to_xfer_partial (ops, object, annex, readbu= f, > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0writebuf, offset, len); > +}=20 You don't really need this. Fix bfd/elf.c to grok the note, and export a .auxv section, just like corelow.c expects, and other archs do. > + =A0core_ops->to_extra_thread_info =3D nto_target_extra_thread_info; Looks like one of two things would be possible here: - a gdbarch callback so that cores can customize this, move the needed code into a nto-tdep.c file, and register the callback. - come up with new fake bfd sections like e.g., ".thrextrainfo/TID" (named similarly to to .reg/TID), whose contents would simply be the string GDB should display, in target_extra_thread_info. Implement suppo= rt for that in bfd and corelow.c. > + =A0core_ops->to_xfer_partial =3D nto_core_xfer_partial; This isn't needed, as explained. > + =A0core_ops->to_pid_to_str =3D nto_pid_to_str; There's already a gdbarch callback for this. > + =A0core_ops->to_find_new_threads =3D nto_find_new_threads_in_core; Then you'd not have a need for this. Do any extra needed processing lazilly in to_extra_thread_info if you must. --=20 Pedro Alves