[Aboriginal] armv4tl floating exception message in guest

[Rob Landley]

On 04/06/2013 09:37:36 AM, mobi phil wrote:
> > Static strace binaries are in the "extras" directory, you should be  
> able to
> > fetch them with wget through the virtual network. They may not have  
> uploaded
> > for this release (200k/second times a large number of megabytes,  
> and I can't
> > upload from this netbook at woork but only out and lunch and such).
> 
> thanks, was not aware about the extras directory

I need to improve the documentation, but haven't figured out how to do  
so without making it so big you can't find anything because of the  
sheer size.

All of my attempts to sit down and systematically document this project  
turn into giant things like  
http://speakerdeck.com/u/mirell/p/developing-for-non-x86-targets-using-qemu  
which isn't what I'm going for. I'm actually pretty happy with how  
_short_ I managed to get the recent rewrite of the about.html page.

> > Adding gdb is a perpetual todo item, I think my most recent stab at  
> it was
> > somewhere around http://landley.net/notes-2010.html#15-02-2010 but  
> mostly I
> > don't use gdb, so I wait for people who do to note its absence.
> 
> you made me curious. can you tell me please what would you have used
> in this particular situation (and restricted environment) to figure
> out where the floating exception is coming from?

We debugged it on this list in December:

    
http://lists.landley.net/pipermail/aboriginal-landley.net/2012-December/000478.html

What I usually do is recompile the source of the offending command and  
stick printf() calls into it until I tracked down the line that was  
faulting. (If it didn't print, that was after the segfault, if it did  
print it was before.) Then I'd print out the values of the calculation  
it was doing and found the division by zero error and trace that data  
back to where it came from.

In this case, somebody else ran gdb on it before I got around to  
looking at it:

    
http://lists.landley.net/pipermail/aboriginal-landley.net/2012-December/000483.html
    
http://lists.landley.net/pipermail/aboriginal-landley.net/2012-December/000484.html

But if you have a build environment set up and can recompile the  
program with extra logging of your choice stuck in anywhere, gdb  
doesn't buy you all that much. Where gdb shines is when you _can't_  
easily do that. Since I'm building this whole system from source...

I sometimes use the -s option of the various qemu variants to hook up  
gdb via "target remote":

   http://landley.net/notes-2008.html#18-03-2008
   http://landley.net/notes-2008.html#19-03-2008

But that's for stuff I can't stick a printf in. (And I've managed to  
stick a printf into the uClibc dynamic linker.) The case above was  
debugging the glue tinycc put between _start and main(). I've also had  
to debug uclibc and qemu disagreeing about what that init code should  
do on powerpc, but gdb wasn't helpful there. (objdump -d was, and I  
stuck printf()s in qemu.)

   http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00800.html
   http://landley.net/notes-2007.html#28-03-2007

Here's a longish debugging session I did without gdb:

   http://landley.net/notes-2011.html#01-09-2011
   http://landley.net/notes-2011.html#02-09-2011
   http://landley.net/notes-2011.html#03-09-2011
   http://landley.net/notes-2011.html#04-09-2011
   http://landley.net/notes-2011.html#05-09-2011

And so on, and so forth. I pull out gdb when I have no other choice,  
but that's almost never the case.

Rob

 1365441082.0