Re: [PATCH/RFC] gdb: tests: add support for testing FLAT toolchains

[Mike Frysinger <vapier@gentoo.org>]

On Fri, Jul 1, 2011 at 11:16, Pedro Alves wrote:
> On Friday 01 July 2011 15:28:17, Mike Frysinger wrote:
>> On Fri, Jul 1, 2011 at 05:16, Pedro Alves wrote:
>> > On Friday 01 July 2011 01:24:41, Mike Frysinger wrote:
>> >> From: Jie Zhang <jie@codesourcery.com>
>> >>
>> >> FLAT toolchains output a FLAT binary for the named output and create
>> >> another file with a .gdb suffix that is used for debugging.  So when
>> >> testing a FLAT toolchain and we need to load up a file, use the .gdb.
>> >
>> > Sounds a lot like the recently added
>> > lib/gdb.exp:exec_target_file/exec_symbol_file hooks?  We added them
>> > to solve the exact same problem.  We then have this in our board file
>> > for uclinux/flat toolchains:
>> >
>> >       proc exec_target_file { binfile } {
>> >           return ${binfile}.flt
>> >       }
>>
>> probably ... this code does date back years ago, and when i poked
>> things again one year ago, it still needed to be done.  i'll take a
>> look at what you refer to now though.
>
> I took another look at how we do things.  Those hooks I pointed at
> are only part of the story, and are not enough for what you
> need --- we _also_ override gdb_compile in our board files, calling
> the existing version, and then doing the renaming very similarly to
> what your patch does.
>
> (What I've wondered before was if it was possible to pass enough
> switches to the tools in order to have them output the files
> with the names we need in the first place, in order to avoid the
> renaming.)

it is possible if the link is done twice, but that isnt better.
bfin-uclinux-gcc ... -o foo -no-elf2flt
bfin-uclinux-gcc ... -o foo.flt
(of course, you would have an extra foo.flt.gdb)

> I'm not super keen on having these target and environment pecularities
> straight in the core testsuite code.  I'd rather we had enough
> hooks to make it easy for a board file or a config file to do what
> it needs to.  E.g., symbian toolchains also have separate binary
> and symbol files (the reason shlib_target_file/shlib_symbol_file
> were added a while ago, uppon which exec_target_file/exec_symbol_file
> were later modelled on), and the extension is not .flt then,
> of course.  Maybe we could do something like
> gdb/testsuite/config/gdbserver.exp/gdb/testsuite/lib/gdbserver-support.exp
> instead?  That is, move your code to new gdb/testsuite/config/flt.exp
> gdb/testsuite/lib/flt-support.exp files that do what you
> have, but by overriding what needs overriding (gdb_compile
> and the exec_*_file hooks mainly)?  WDYT?

i dont need the logic to be in the core gdb testsuite, but i think it
does have to be in the gdb testsuite somewhere.  i dont think making
all board porters do the same thing over and over again is the right
path.  after all, this is going to be the same issue across all
toolchains that target this binary format.  which is what we just
found out since i doubt the code you have is for Blackfin processors
:).

it seems like the shlib/exec hooks you mention should be sufficient.
do you know why in your setup you still need to bang on gdb_compile ?
-mike