Re: RFC for: "Re: Regression for gdb.fortran/library-module.exp [Re: [RFA] choose symbol from given block's objfile first.]"

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Mon, 28 May 2012 16:27:27 +0200, Joel Brobecker wrote:
> I just want to make sure that we do not get carried away trying to
> implement the perfect solution, because I don't have the time in
> the next few weeks to implement it, and I don't even know how to
> do that at the moment.

I somehow also share this approach currently.


> What the code above does, in practice, is trying to go through
> the ALL_OBJFILES list in the same order as before, except that
> we try the "context" objfile file first.  But, to make things
> even more interesting, having a "context" objfile does not mean
> that it should be checked ahead of any MAINLINE objfile, because
> otherwise we break your Fortran test.

Just the MAINLINE exception is not enough, it still regresses GDB:

==> 50.c <==
//extern int v;
extern int f (void);
extern int g (void);
int main (void) {
  return 10 * f () + g ();
}
==> 50l.c <==
int v=1;
int f (void) {
  return v;
}
==> 50ll.c <==
int v=2;
int g (void) {
  return v;
}
==============
gcc -o 50l.so 50l.c -Wall -g -shared -fPIC;gcc -o 50ll.so 50ll.c -Wall -g -shared -fPIC;gcc -o 50a 50.c -Wall -g ./50l.so ./50ll.so;gcc -o 50b 50.c -Wall -g ./50ll.so ./50l.so;./50a;echo $?;./50b;echo $?
for e in 50a 50b;do ./$e;echo $?;./gdb -q ./$e -ex 'b f' -ex 'b g' -ex r -ex 'p v' -ex c -ex 'p v' -ex c -ex q;done

before your patches (and therefore matching GDB the inferior behavior):
11
$1 = 1
$2 = 1
22
$1 = 2
$2 = 2

with your final patches (undo the first, apply this WIP second patch)
11
$1 = 1
$2 = 2
22
$1 = 1
$2 = 2

GDB is just behaving right in normal cases.

GDB is not correct, that it does not correctly maintain objfiles order in the
case of some dlopens/dlcloses (at least I guess so, I did not try to
reproduce).


> Another way of expressing
> the intent of my patch is to say: Try the "context" objfile first,
> unless it's not a MAINLINE objfile, in which case we try the
> MAINLINE objfiles, and then our "context" objfile.

But '"context" objfile first' is incompatible with SVR4.  The behavior
apparently has to be target specific.


> So, we have two options, at this point:
> 
>   (1) Revert my original patch;
> 
>   (2) Enhance the heuristics in my patch. This second patch is an
>       attempt at this.
> 
> I think it would be a loss to revert, but if we cannot converge on
> the heuristics for the search, then we'll just go to the previous
> search order (which may also be arbitrary in some ways).

Not sure what do you call 'heuristics' but as long as it becomes target
dependent the patch should be simple.


Thanks,
Jan