Re: [Gcl-devel] ANSI Windows: in-package failure

[Camm Maguire]

Greetings!

Mike Thomas <address@hidden> writes:

> ===================================================
> 
> Just here it hangs (at least for five minutes.  Am I being unrealistic to 
> expect unexec to work
> under a debugger?

Watchpoints can be quite slow.  I'd suggest reaching your unexec
breakpoint first, then enabling the watch, after inspecting the
contents at &null_string first, of course.

> 
> I was watching the location of null_string in case it's being overwritten 
> rather than something
> being wrong with the unexec algorithm per se
> 
> I'll try and poke around in the unexec process with printf debugging but for 
> now I'm probably
> off-line for this evening.
> 
> Also, in answer to another question you asked a while ago and I neglected to 
> answer - yes - I still
> have your modified source tree from the work you did on my computer.  When I 
> looked at it at the
> time I found that your configuration was treating the build as Cygwin which 
> is not good.  I think
> it's a bit late to be changing the entire unexec file for 2.6.2 though.
> 

While I cannot recall exactly the steps I took, my impression was that
the incorporation of unexw32.c was pretty straightforward.  Is it
possible you might have saved some email correspondence we shared at
this time on this subject?  In any case, if unexw32.c is easy, I don't
think it is too late for stable -- we don't write or maintain these
files (in general) anyway, rather emacs does.  The one exception to my
knowledge is the expansion of the allowed heap (if memory serves it
was in this file) which probably would have been taken care of in the
new unexew32.c file anyway.  I'm hoping my cygwin experiments were
more due to trying to get a working bfd, but I could be mistaken.  

I'd suggest trying the above break sequence.  If the problem is in
unexec, as I suspect, look in firstfile.c and lastfile.c (I think) and
figure out where the beginning and ending dump addresses are.  Is it
possible the static null_string is at an address outside this range?
If nothing clear emerges and an extensive analysis of unexnt.c becomes
necessary, try your hand at a quick substitution of unexw32.c

> Also again, is it possible to get the debugger to watch for reads of a memory 
> location eg to see if
> unexec actually reads the location of null_string during startup.
> 

Not to my knowledge, which is very partial when it comes to gdb.  I've
learned about a number of commands (like 'finish') from your posts.

Take care,

> Cheers
> 
> Mike Thomas
> 
> 
> >Take care,
> >
> >
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah