RE: Debugging with no serial port

RE: Debugging with no serial port

[Martin, Tim]

Ben,

>	How about something a bit simpler like running gdb within a
'script' context,
> which will log your session to a file.  Get gdb to print the variables
to the screen
> (using 'print' or whatever), wrap your data with easily searchable
characters=20
> (eg. ***data1 data2 data3***), then filter your data from the script
file with sed/awk
> or perl scripts?
=09
I tried this as well and have the same GDB synchronization problem e.g.

break log_stuff
commands
   silent
   if (variable_logging_enabled)
      printf "(%d,%d)\n",stuff1_variable,stuff2_variable
   end
   cont
end

The printf's don't complete before the cont happens.  Sounds like maybe
this is a GDB problem...

Tim
=09

RE: Debugging with no serial port

[Ben Warren]

Martin,

On Thu, 2006-08-10 at 13:12 -0700, Martin, Tim wrote:

> 	
> I tried this as well and have the same GDB synchronization problem e.g.
> 
> break log_stuff
> commands
>    silent
>    if (variable_logging_enabled)
>       printf "(%d,%d)\n",stuff1_variable,stuff2_variable
>    end
>    cont
> end
> 
That's too bad.  I wonder if you could run gdb from expect or some other
auto-scripting language and have it issue the 'cont' once all data is
printed (Have your code spit out a special 'end of data' delimiter). 

Just a thought - no idea if it would work.  

I'm not 100% certain how BDI-2000/gdb works, but I guess the gdb server
is running on the box, in which case you probably don't have much
control over how it works, and thus can't control if the output stream
is buffered or not.  My BDI-2000 book doesn't have much on configuring
the gdb part.

Anyway, sorry for rambling.

regards,
Ben

RE: Debugging with no serial port

[Martin, Tim]

=20
> > =09
> > I tried this as well and have the same GDB synchronization=20
> problem e.g.
> >=20
> > break log_stuff
> > commands
> >    silent
> >    if (variable_logging_enabled)
> >       printf "(%d,%d)\n",stuff1_variable,stuff2_variable
> >    end
> >    cont
> > end
> >=20
> That's too bad.  I wonder if you could run gdb from expect or=20
> some other auto-scripting language and have it issue the=20
> 'cont' once all data is printed (Have your code spit out a=20
> special 'end of data' delimiter).=20
>=20
> Just a thought - no idea if it would work. =20
>=20

What a brilliant idea!  I tried this and it works perfectly.  Having no
previous expect experience, I was able to generate and modify the expect
script with "autoexpect" in about 10 minutes.

Thanks!
Tim

RE: Debugging with no serial port

[Martin, Tim]

=20
>> Second question would be - is there an easier way to accomplish what=20
>> I'm trying to do, which is basically emulate a serial port with GDB.

>=20
> Use NetConsole or remotey log it with syslog...
>=20

I guess I wasn't clear in the problem statement - this target doesn't
have a serial port, an ethernet port, or a file system.  So I can't log
over Ethernet or log by writing to a file.  I'm fairly restricted to
getting data out of the system using GDB controlling a hardware JTAG
debugger (think BDI2000).

Tim

Re: Debugging with no serial port

[Brian Waite]

On Thursday 10 August 2006 15:00, Martin, Tim wrote:
> >> Second question would be - is there an easier way to accomplish what
> >> I'm trying to do, which is basically emulate a serial port with GDB.
> >
> > Use NetConsole or remotey log it with syslog...
>
> I guess I wasn't clear in the problem statement - this target doesn't
> have a serial port, an ethernet port, or a file system.  So I can't log
> over Ethernet or log by writing to a file.  I'm fairly restricted to
> getting data out of the system using GDB controlling a hardware JTAG
> debugger (think BDI2000).
I don't know GDB internals so I cannot answer the specific question relating 
to synchronous writes via GDB.
But...
How much data are we talking and is there some area of private memory to stash 
the logged data in and use the JTAG adapter to fetch the memory blocks and 
write to a local file for post processing? I've done this in places where I 
am doing kernbel bringup without a serial port. Your other option is use a 
few IO pins (if available) and make a bit banging serial interface with some 
extrnal components. 

Thanks
Brian

Debugging with no serial port

[Martin, Tim]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

This may be more of a question for GDB folks...but I'll post it here
because it relates to embedded systems as well.
 
I'm trying to validate some signal processing software on an embedded
Virtex4 PowerPC 405.  Basically, the validation consists of calling
functions and looking at their outputs.  Over time, there are several
thousand numbers to look at, so manually looking at each number at a
break point would be very time consuming (to put it mildly).
 
The normal way I would go about doing this is to print out the data
(e.g. to a serial port) and post-process the data somewhere else.  But
on this particular target, I don't have a serial port.  So I thought
about using GDB's breakpoint command list feature.  When the software
has data it wants to print out, it calls a function "log_stuff".  I then
set a breakpoint and command list in the "log_stuff" function, which
writes out the variables I'm interested in checking out to a file named
outputfile.bin.  E.g. the following command file does this:
 
break log_stuff
commands
   silent
   if (variable_logging_enabled)
      append value outputfile.bin stuff1_variable
      append value outputfile.bin stuff2_variable
   end
   cont
end
 
The problem I have with this approach is that GDB doesn't finish writing
out everything before it continues executing the program, so a backlog
develops.  So my first question would be, is there some GDB "flush" like
command I could run before the cont statement?
 
Second question would be - is there an easier way to accomplish what I'm
trying to do, which is basically emulate a serial port with GDB.
 
Tim
 

[-- Attachment #2: Type: text/html, Size: 3784 bytes --]

Re: Debugging with no serial port

[Frank]

--- "Martin, Tim" <tim.martin@viasat.com> wrote:

> This may be more of a question for GDB folks...but I'll post
> it here
> because it relates to embedded systems as well.
>  
> I'm trying to validate some signal processing software on an
> embedded
> Virtex4 PowerPC 405.  Basically, the validation consists of
> calling
> functions and looking at their outputs.  Over time, there are
> several
> thousand numbers to look at, so manually looking at each
> number at a
> break point would be very time consuming (to put it mildly).
>  
> The normal way I would go about doing this is to print out the
> data
> (e.g. to a serial port) and post-process the data somewhere
> else.  But
> on this particular target, I don't have a serial port.  So I
> thought
> about using GDB's breakpoint command list feature.  When the
> software
> has data it wants to print out, it calls a function
> "log_stuff".  I then
> set a breakpoint and command list in the "log_stuff" function,
> which
> writes out the variables I'm interested in checking out to a
> file named
> outputfile.bin.  E.g. the following command file does this:
>  
> break log_stuff
> commands
>    silent
>    if (variable_logging_enabled)
>       append value outputfile.bin stuff1_variable
>       append value outputfile.bin stuff2_variable
>    end
>    cont
> end
>  
> The problem I have with this approach is that GDB doesn't
> finish writing
> out everything before it continues executing the program, so a
> backlog
> develops.  So my first question would be, is there some GDB
> "flush" like
> command I could run before the cont statement?
>  
> Second question would be - is there an easier way to
> accomplish what I'm
> trying to do, which is basically emulate a serial port with
> GDB.
>  
> Tim

Use NetConsole or remotey log it with syslog...

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Debugging with no serial port

[Ben Warren]

[-- Attachment #1: Type: text/plain, Size: 2322 bytes --]

Tim,

How about something a bit simpler like running gdb within a 'script'
context, which will log your session to a file.  Get gdb to print the
variables to the screen (using 'print' or whatever), wrap your data with
easily searchable characters (eg. ***data1 data2 data3***), then filter
your data from the script file with sed/awk or perl scripts?

A bit brute force, but bound to work.

regards,
Ben

On Thu, 2006-08-10 at 10:14 -0700, Martin, Tim wrote:
> This may be more of a question for GDB folks...but I'll post it here
> because it relates to embedded systems as well.
>  
> I'm trying to validate some signal processing software on an embedded
> Virtex4 PowerPC 405.  Basically, the validation consists of calling
> functions and looking at their outputs.  Over time, there are several
> thousand numbers to look at, so manually looking at each number at a
> break point would be very time consuming (to put it mildly).
>  
> The normal way I would go about doing this is to print out the data
> (e.g. to a serial port) and post-process the data somewhere else.  But
> on this particular target, I don't have a serial port.  So I thought
> about using GDB's breakpoint command list feature.  When the software
> has data it wants to print out, it calls a function "log_stuff".  I
> then set a breakpoint and command list in the "log_stuff" function,
> which writes out the variables I'm interested in checking out to a
> file named outputfile.bin.  E.g. the following command file does this:
>  
> break log_stuff
> commands
>    silent
>    if (variable_logging_enabled)
>       append value outputfile.bin stuff1_variable
>       append value outputfile.bin stuff2_variable
>    end
>    cont
> end
>  
> The problem I have with this approach is that GDB doesn't finish
> writing out everything before it continues executing the program, so a
> backlog develops.  So my first question would be, is there some GDB
> "flush" like command I could run before the cont statement?
>  
> Second question would be - is there an easier way to accomplish what
> I'm trying to do, which is basically emulate a serial port with GDB.
>  
> Tim
>  
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

[-- Attachment #2: Type: text/html, Size: 4628 bytes --]