Re: GDB testsuite overrides default_target_compile and breaks

Tom Tromey <[email protected]>
Newsgroups gmane.comp.gdb.devel,gmane.comp.sysutils.dejagnu.general
Message-ID <[email protected]>
I trimmed the cc list down to just gdb and dejagnu.

Jacob> What is needed in brief:
Jacob> (1) Merge the features of default_target_compile that the GDB
Jacob> testsuite depends on upstream for 1.6.3.
Jacob> (2) Find the actual extensibility that GDB needs here and add that
Jacob> support to the default_target_compile rewrite slated for 1.6.4.

Sounds reasonable to me.

Jacob> The changes were to an internal component and broke an out-of-tree
Jacob> copy of same.  I have to draw a line somewhere, and "monkeypatching
Jacob> the core is not supported and can break" is necessary for DejaGnu to
Jacob> develop at all.

FWIW this makes sense to me.  I think it's never been a great idea to
have this override in gdb.  Dejagnu wasn't very actively maintained for
a long time, and had low engagement from gdb developers, so it was more
like a convenient way to move forward.

Jacob> Monkeypatching the DejaGnu core is not supported and cannot be
Jacob> supported long-term.

gdb does it other spots as well.  For example, check-test-names.exp
overrides log_summary and reset_vars that gdb can show duplicated test
names, and gdb.exp renames "cd" to avoid problems with relative log file
names.

Jacob> GDB seems to have also extended default_target_compile, so a
Jacob> discussion on this is needed because there seems to be a need for some
Jacob> kind of language extensibility feature to allow new
Jacob> language-default-selector options to be defined without overriding the
Jacob> entire default_target_compile procedure

Yes, that would be good to have.  I think this has been patched when a
new language is added to gdb; changing this function to work in some
extensible way would be a nice improvement... while there are no
concrete plans I know of to add new languages to gdb, one never knows
when someone may show up with patches.

Jacob> If I understand correctly, merging the features currently carried in
Jacob> gdb/testsuite/lib/future.exp upstream will cause all existing GDB 
Jacob> releases to correctly use the upstream version of
Jacob> default_target_compile, making the partial reversion patch
Jacob> unnecessary.

Yes, assuming that gdb's detection code continues to work.  It does
this:

    if {[info procs find_gnatmake] == ""} {
        rename gdb_find_gnatmake find_gnatmake
        set use_gdb_compile 1
    }
    # ... sequence of such checks ...
    if {$use_gdb_compile} {
        catch {rename default_target_compile {}}
        rename gdb_default_target_compile default_target_compile
    }

Anyway, I compared gdb_default_target_compile with
default_target_compile.  I think there are two kinds of changes.

One is the addition of new languages, namely Rust and Go.  This seems
relatively straightforward.

The other is the addition of "early_flags":

	if {[regexp "^early_flags=" $i]} {
	    regsub "^early_flags=" $i "" tmp
	    append early_flags " $tmp"
	}
...
    switch $type {
	"object" {
	    set opts "$early_flags $add_flags $sources"
	}
        ... etc

This seems to be needed to adapt to some distro-specific compiler
issues.  One example is:

		if { [test_compiler_info "gcc-*"] || [test_compiler_info "clang-*"] } {
		    # Undo debian's change in the default.
		    # Put it at the front to not override any user-provided
		    # value, and to make sure it appears in front of all the
		    # shlibs!
		    lappend new_options "early_flags=-Wl,--no-as-needed"
		}

I can write some patches to merge this stuff in.

Tom
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.