GNU bug report logs - #66984
target_alias variable set incorrectly

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66984 in the body.
You can then email your comments to 66984 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eugene Sharygin <eush <at> ispras.ru>
To: bug-dejagnu <at> gnu.org
Subject: target_alias variable set incorrectly
Date: Tue, 07 Nov 2023 15:49:18 +0300

The bug manifests when trying to call `transform` on a tool name with a 
non-null
`target_triplet`.

Minimal code to reproduce:

> $ cat xyz.exp
> puts "size is [transform size]"
> $ runtest --target=powerpc-linux-gnu
> [snip]
> size is -size

> $ runtest --version
> DejaGnu version 1.6.3
> Expect version 5.45.4
> Tcl version 8.6

If run without a `--target` flag, it outputs "size is size", as 
expected.
However, if `--target` is specified, it prints "size is -size" instead 
of
the expected output, which is "powerpc-linux-gnu-size".

The reason being the `target_alias` variable, which is initially 
assigned [1] to
an empty string in `runtest.exp`, and which is then supposed to be 
defaulted
to the value of `target_triplet`, with the following code:

> if {![info exists target_alias]} {
>     set target_alias $target_triplet
> }

Of course, `info exists` returns 1 on a variable set to an empty string.

My proposed change is simply to omit the initial assignment of 
`target_alias`,
like this:

> --- runtest.exp.orig	2023-11-07 15:21:39.000000000 +0300
> +++ runtest.exp	2023-11-07 15:37:49.802466623 +0300
> @@ -82,7 +82,6 @@
>  set target_os	   ""		;# type of os the tests are running on
>  set target_vendor  ""		;# vendor name of the OS or workstation the 
> test are running on
>  set target_cpu     ""		;# type of the cpu tests are running on
> -set target_alias   ""		;# standard abbreviation of target
>  set compiler_flags ""		;# the flags used by the compiler
> 
>  #

[1]: 
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=blob;f=runtest.exp;h=84c7e28e117abff450e2aa9a8b9bbb1e618f0040;hb=HEAD#l85
[2]: 
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=blob;f=runtest.exp;h=84c7e28e117abff450e2aa9a8b9bbb1e618f0040;hb=HEAD#l890

-- Eugene

Message #8 received at 66984 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Eugene Sharygin <eush <at> ispras.ru>
Cc: 66984 <at> debbugs.gnu.org
Subject: Re: bug#66984: target_alias variable set incorrectly
Date: Tue, 07 Nov 2023 21:15:47 -0600

Eugene Sharygin wrote:
> [...]
>
> The reason being the `target_alias` variable, which is initially 
> assigned [1] to
> an empty string in `runtest.exp`, and which is then supposed to be 
> defaulted
> to the value of `target_triplet`, with the following code:
>
>> if {![info exists target_alias]} {
>>     set target_alias $target_triplet
>> }

I suspect that this bug went unnoticed for so long because site.exp is 
supposed to set target_alias, but site.exp can now be optional in some 
cases.

> Of course, `info exists` returns 1 on a variable set to an empty string.
>
> My proposed change is simply to omit the initial assignment of 
> `target_alias`, [...]

The main problem I have with that change is that existing code might 
(incorrectly) depend on target_alias being set to an empty string and I 
have a better way to fix the problem that avoids that risk of causing 
breakage:  fix the tests to check that target_alias is non-empty instead 
of merely being set.  I have pushed commit
a877b418a00dcc3c5b4d7584e0d85949c843c4ed to branch PR66984 on Savannah; 
please confirm that it solves your problem so I can merge it to master 
and close the bug report.


-- Jacob

Message #11 received at 66984 <at> debbugs.gnu.org (full text, mbox):

From: Eugene Sharygin <eush <at> ispras.ru>
To: jcb62281 <at> gmail.com
Cc: 66984 <at> debbugs.gnu.org
Subject: Re: bug#66984: target_alias variable set incorrectly
Date: Wed, 08 Nov 2023 13:40:08 +0300

On 2023-11-08 6:15 am, Jacob Bachmeyer wrote:
> I have pushed commit a877b418a00dcc3c5b4d7584e0d85949c843c4ed to branch 
> PR66984 on
> Savannah; please confirm that it solves your problem so I can merge it
> to master and close the bug report.

I do confirm that the fix solves my problem, thank you so much for 
prompt response!

-- Eugene

Message #16 received at 66984-done <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Eugene Sharygin <eush <at> ispras.ru>
Cc: 66984-done <at> debbugs.gnu.org
Subject: Re: bug#66984: target_alias variable set incorrectly
Date: Wed, 08 Nov 2023 22:15:20 -0600

Eugene Sharygin wrote:
> On 2023-11-08 6:15 am, Jacob Bachmeyer wrote:
>> I have pushed commit a877b418a00dcc3c5b4d7584e0d85949c843c4ed to 
>> branch PR66984 on
>> Savannah; please confirm that it solves your problem so I can merge it
>> to master and close the bug report.
>
> I do confirm that the fix solves my problem, thank you so much for 
> prompt response!

You are welcome; thank you for your prompt response.


-- Jacob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.