From: Simon Marchi <simark@simark.ca>
To: "Jose E. Marchesi" <jose.marchesi@oracle.com>,
gdb-patches@sourceware.org
Cc: indu.bhagat@oracle.com, elena.zannoni@oracle.com
Subject: Re: [PATCH V3] gdb: link executables with libtool
Date: Mon, 7 Nov 2022 08:26:48 -0500 [thread overview]
Message-ID: <bb78fc0f-0208-7c39-72b9-2ea28dc84e17@simark.ca> (raw)
In-Reply-To: <20221106131041.1221924-1-jose.marchesi@oracle.com>
On 11/6/22 08:10, Jose E. Marchesi via Gdb-patches wrote:
> [Changes from V2:
> - Add .. to AC_CONFIG_MACRO_DIRS so autoreconf DTRT.
> - Refer to libopcode as a libtool library.
> - Do not use libtool --mode=execute in testsuite/lib/gdb.exp.
> - Remove spurious entry from top-level ChangeLog.
> - Remove ChangeLog fragment from commit message.
> - Add git trailer to commit message.
> - Typos fixed in commit message.]
>
> This patch changes the GDB build system in order to use libtool to
> link the several built executables. This makes it possible to refer
> to libtool libraries (.la files) in CLIBS.
>
> As an application of the above,
>
> BFD now refers to ../libbfd/libbfd.la
> OPCODES now refers to ../opcodes/libopcodes.la
> LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
> LIBCTF now refers to ../libctf/libctf.la
>
> NOTE1: The addition of libtool adds a few new configure-time options
> to GDB. Among these, --enable-shared and --disable-shared, which were
> previously ignored. Now GDB shall honor these options when linking,
> picking up the right version of the referred libtool libraries
> automagically.
>
> NOTE2: I have not tested the insight build.
>
> NOTE3: For regenerating configure I used an environment with Autoconf
> 2.69 and Automake 1.15.1. This should match the previously
> used version as announced in the configure script.
>
> NOTE4: Now the installed shared object libbfd.so is used by gdb
> if binutils is installed with --enable-shared.
>
> Testing performed:
>
> - --enable-shared and --disable-shared (the default in binutils) work
> as expected: the linked executables link with the archive or shared
> libraries transparently.
>
> - Makefile.in modified for EXEEXT = .exe. It installs the binaries
> just fine. The installed gdb.exe runs fine.
>
> - Native build regtested in x86_64. The installed gdb runs fine.
>
> In the regression testing I'm observing that the following tests
> doesn't seem to be deterministic:
>
> gdb.base/step-over-syscall.exp
> gdb.threads/process-dies-while-detaching.exp
> gdb.threads/process-dies-while-handling-bp.exp
>
> Sometimes some of the the tests in these files unexpectedly fail,
> like in:
>
> -PASS: gdb.threads/process-dies-while-detaching.exp: single-process: \
> continue: detach: continue
> +FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: \
> continue: detach: continue
>
> Sometimes they unexpectedly pass:
>
> -KFAIL: gdb.base/step-over-syscall.exp: clone: displaced=on: \
> check_pc_after_cross_syscall: single step over clone \
> final pc (PRMS: gdb/19675)
> +PASS: gdb.base/step-over-syscall.exp: clone: displaced=on: \
> check_pc_after_cross_syscall: single step over clone final pc
>
> -KFAIL: gdb.threads/process-dies-while-handling-bp.exp: \
> non_stop=on: cond_bp_target=0: inferior 1 exited \
> (prompt) (PRMS: gdb/18749)
> +PASS: gdb.threads/process-dies-while-handling-bp.exp: \
> non_stop=on: cond_bp_target=0: inferior 1 exited
>
> - Cross build for aarch64-linux-gnu built to exercise
> program_transform_name and friends. The installed
> aarch64-linux-gnu-gdb runs fine.
>
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
> ---
> gdb/Makefile.in | 14 +-
> gdb/aclocal.m4 | 5 +
> gdb/config.in | 4 +
> gdb/configure | 31544 ++++++++++++++++++++++++++++++---------------
> gdb/configure.ac | 17 +-
This diffstat claims there are changes to configure, but the patch
doesn't actually has them. Perhaps it's on purpose, because they are a
bit on the big side to send by email. I'd just like to double-check
that when I run autoreconf on my side, I get the same result as you.
Could you perhaps upload your patch to a git branch? It could be a user
branch here in the sourceware binutils-gdb repo.
Simon
next prev parent reply other threads:[~2022-11-07 13:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-06 13:10 Jose E. Marchesi
2022-11-07 13:26 ` Simon Marchi [this message]
2022-11-07 14:14 ` Jose E. Marchesi
2022-11-07 14:23 ` Simon Marchi
2022-11-07 15:55 ` Jose E. Marchesi
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=bb78fc0f-0208-7c39-72b9-2ea28dc84e17@simark.ca \
--to=simark@simark.ca \
--cc=elena.zannoni@oracle.com \
--cc=gdb-patches@sourceware.org \
--cc=indu.bhagat@oracle.com \
--cc=jose.marchesi@oracle.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).