Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

[Peter Rosin]

Den 2010-09-09 22:05 skrev Charles Wilson:
> On 9/9/2010 3:56 PM, Ralf Wildenhues wrote:
>> I understand that you're doing a difficult bug hunt here, and 6/7 is the
>> only unapplied patch of this series (right?).  I've looked at 6/7 again,
>> and conclude that it has a low chance of regressing.
> 
> I agree.

Both 6/7 and 7/7 are outstanding. Both relate to running a Win32 native
toolchain in Wine or in Cygwin and are in my "priority 3" category if
you remember my classification (1 gnu, 2 msvc on msys). So not very
important for the pending release, but still nice to have of course.
I'm sure Christopher likes them though, as he does not want to use MSYS.

For 6/7 (several $NM invocations) testsuite coverage was requested.
If this patch is revised to use the new LAZY argument, the patch will
have even less impact. But it will also require a weirder setup to
tickle the new code.

For 7/7 (prefer $NM @file) Ralf suggested that we should keep to the
current scheme as much as possible and not use the @file branch unless
needed as the @file branch made debugging harder. Since the @file branch
is also slower on MSYS it should probably be avoided there for that
reason too. But the current primary scheme only works when
to_tool_file_cmd is a noop (and on MSYS) when facing absolute file
names, so something needs to be done.

Other than that, I have two identified testsuite weaknesses that could
be fixed, but that's not very important at all.

Look at the above as a status report written since there seem to be
confusion in that area. I intend to post new messages with more exact
info on what I want to happen with the outstanding 6/7 and 7/7 patches.
But not today.

>> If it makes things easier for you, then I'm fine with you going ahead
>> and applying the patch.
> 
> I don't think the uncommitted portions of Peter's series affect this
> particular bug hunt (now that the one regression has been corrected).
> This one is all me. :-(
> 
> OTOH, I'm sure Peter would be very happy to push his remaining patches...

See above.

>> Secondly, I can help with unsupervised git bisect if you need.  In
>> <http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg00006.html>,
>> I posted a bisect script for a slightly different bug; for your case,
>> you should adjust reconfdirs (for efficiency) and TESTS and the failure
>> grep.  In the 'git bisect start' command line, you need to specify one
>> known-bad and one known-good revision.

I adjusted both reconfdirs and TESTS. You tend to learn how to do that
quickly in windows-land. The payoff for that learning curve is almost
instantaneous.

> I'll take a look, but it may actually be faster to do it old-school:
> just trace thru the failing case in git master-NOW, figure out what's
> going wrong, and fix it.

In my current setup it's hard to automate, as I do git and bootstrap on
Cygwin only, then test Cygwin and when that is done I switch to MSYS and
test there too. I have version mismatches for automake and autoconf in
MSYS and Cygwin, so if I'm not careful things go belly up. I should
perhaps try to have matching autotools, but I'm used to not having them
at all in MSYS, and I'm not sure if things will be screwed up with paths
leaking in from the other posix world if I mix, so I'm just doing it in
a way that I know works.

>> Last but not least, IIUC then you've complained about possibly multiple
>> failures masking.  Is this specifically about the stresstest?  To
>> alleviate this in the future, we can modify stresstest to fan it out
>> into several test groups (so separate issues have a higher chance of
>> producing separate failures), or modify it so it runs all tests (even if
>> some failed earier) and summarizes the failing instances at the end.
> 
> Naw, it's not stresstest.  It's just mdemo (and mdemo-2) really push all
> the various bits of libtool and libltdl very hard.  It's a very good
> test that way.

Watch out, rant coming up. You have been warned.

My problem(?) is that libltdl issues are the hardest to fix, so there
are multiple issues that are not fixed for MSVC. That, and that most
libltdl tests are too wide for my liking, so the libltdl part of the
testsuite tend to either be all failing or all failing even if you have
made an improvement. Which makes it hard to use the testsuite to
determine if you have made any progress when you are testing something.
It is also hard to deduce if you have caused some spectacular new fail
with a patch, if the test in question fails before it got to the newly
introduced badness. Even if the the new fail happens before the old
fail, it's still harder to discriminate fail:63 from fail:67 than it is
to discriminate fail:63 from ok. It also doesn't really help that I'm
not using libltdl for anything real: I'm not really familiar with what
the expected behavior is and it tends to not be that important and
"itchy" to me.

And then, as always, there's the wall clock issue. You can have many
ideas while you are waiting for the testsuite, and when it finally
finishes you have forgotten what it was you were thinking when it
started, which also makes it harder to connect the new results
with those old ideas. Similarly if you have moved on to something
completely different before you get the results, which is perhaps
the more common scenario. I'd like to have more immediate feedback,
but that's just wishful thinking of course. It's just painful and
there's no fix in sight, everybody knows it, and I don't know why I
bother knocking in this open door.

stresstest is now ok for MSVC, so it is finally really useful in
detecting regressions, and no longer a "masking failure rat hole".

Cheers,
Peter