This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 2/2] Fix linking on non-x86* after libgdb.a removal
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