This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]


On 04/03/2012 17:49, Sergei Gavrikov wrote:
> [...]
>  
> Hi Alex
>
> I just wonder, is there
>
>   set cyg_test_is_simulator=0
>
> line in your gdbinit file?
We don't use gdbint.  Our testfarm uses a mixture of perl and expect to
drive the tests, mainly so we can add additional automatic diagnostic
code when something goes wrong.

Anyway, as I mentioned, the tests do not even hit the initial
cyg_test_init breakpoint so they do not get to that stage.


> [...]
>
>
> GDB 7.3.1
>
> (gdb) set cyg_test_is_simulator=0
> No symbol "cyg_test_is_simulator" in current context.
>
> IMHO, this claim is okay, adn GDB 7.3.1 does not process the next lines in
> gdbinit.
It is OK.  Not as bad as some versions of gdb which interpreted no
symbol as NULL and so would write 0 to NULL.  They always gave
interesting results, but the gdb code segment below worked around this:
if &cyg_test_is_simulator!=0
set cyg_test_is_simulator=0
end

FWIW, using gdbinit or user-defined command files does not always work
for this exact reason - gdb will stop on the first error.  This is why
we have our own scripts, although you could also use the gui configtool
which uses a simplistic but reasonable approach.

However, dropping "set cyg_test_is_simulator=0" for running tests on
hardware is a good idea since it will be zero as it is in .bss.    You
could try the code segment above as another alternative.

-- Alex


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]