Re: [patch 2/2] Fix linking on non-x86* after libgdb.a removal

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

On Thu, 05 Jan 2012 15:46:19 +0100, Ulrich Weigand wrote:
> Jan Kratochvil wrote:
> > For targets using new set_gdbarch_regset_from_core_section it would not be
> > a problem, just put corelow.o into the right entry of gdb/configure.tgt.
> 
> Huh, at least for s390 this would certainly be the correct solution; the
> target actually is fully switched to modern gdbarch core handling ...

I agree and I forgot to write that at least some - at least s390 - targets
properly work with core files on cross-gdb.  But still some other targets do
not.  I find such fix(es) outside of the scope of this proposed patch.
As I found for example on sparc*-tdep.c files it is not so obvious which are
and which are not already converted.


> This needs to be done anyway to properly handle cross-debugging targeting
> s390 core files.  Unless you already have done so, I can prepare a patch.

Sure such (separate) patch would be great.


> Maybe a better way would be to just unconditionally add corelow.o to
> COMMON_OBS and be done with it?  What would be the harm in having the
> core target always present, even in configurations where no core file
> formats will be recognized?

Currently GDB writes:
GDB can't read core files on this machine.

I guess it will load the core file without recognizing its registers?
I do not have available any core file from the legacy *-tdep.c archs.
That can be considered a regression.


> Or, if we want to keep the existing behaviour exactly, we could just
> filter out all objects from TARGET_OBS that are already present in
> NATDEPFILES (or vice versa).  This would at least avoid the ad-hoc
> handling of one specific file ...

I think one cannot do such filtering in a cross-platform way from Makefile.
But I agree it can be done from configure.ac.  I can rework it that way.

There needs to be some exception for ALL_TARGET_OBS which are not known to
configure.ac, I considered this as a blocker but I see it is not.


Thanks,
Jan