[M3devel] pixmap problem

Randy Coleburn rcoleburn at scires.com
Sun Jan 20 20:10:46 CET 2008 

Mika / Daniel:  Thanks for the test info!
 
Well, based on what ya'll are reporting, I think the problem has to do
with the NT386 platform.  I also don't think it has to do necessarily
with the source code.  So, there must be something fishy going on in the
NT386 world in the linkage step to cause this type of situation when
switching between regular and buildstandalone().
 
Unfortunately, I'm probably not the right person to figure out what is
wrong and fix it either.  Hey, but at least I produced a short test
program that reproduces the problem.
 
Maybe Jay or someone can offer another suggestion on how to fix it.
 
I do know for sure that the TestPixmap program does build and run
correctly on cm3 v4.1 for both buildstandalone() and regular.  So, there
must be something that has changed since then to cause this behavior. 
Maybe there is some different argument set that needs to get passed to
the linker.  I don't know.
 
Regards,
Randy

>>> Mika Nystrom <mika at async.caltech.edu> 1/19/2008 10:41 PM >>>

It works great on NT386GNU, PM3/Klagenfurt, as well, without the
build_standalone.

    Mika

"Daniel Alejandro Benavides D." writes:
>--0-1095273535-1200761640=:77597
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: 8bit
>
>Hi:
>The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy
2.6.22-14-386, 32 bits machine.
>
>Thanks
>
>
>Jay <jayk123 at hotmail.com> wrote:    .hmmessage P { margin:0px;
padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma }  I
can repro
> the two different behaviors on XP.
> I was going to try on PPC_DARWIN but I guess Tony's info suffices.
>  
> I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
>  
> Debugging here is a big humungous pain.
> NT386 has good stacks and line numbers, but no locals or type info,
I'd really sometime like to get Codeview info into those .objs...I think
it
> is documented well enough, but still not necessarily easy, or maybe
have a C generating backend partly for this reason (and to bring up more
ta
>rgets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm
> not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info
>, and I'm not familiar with the relevant code. In gdb I struggle just
to view bytes in memory, add numbers to addresses and see those, etc. I
th
>ink for MY problem, I'm going to link in C code to dump the structs.
There is tracing code and I enabled it, but even it crashes in
Text_Length.
> At least MY problem crashes, hopefully near the problem, whereas your
problem goes all the way through to completion with
> no stopping to hint where the problem is. Darn it. :) on the mock
rudeness and :( on the lack of a crash.
>  
> You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
> And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
> Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal 
>something.
>  
> The bad behavior has like regularly spaced solid color veritical bars
a few pixels side across the whole picture, and regularly spaced
vertical
> stripes from the correct picture alternating with that. Perhaps
someone with ppm/bitmap/graphics experience has seen this behavior and
it resul
>ts from some common pixmap mismanagement we could look for?
>  
> I have to say this is very surprising.
>  
> I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports 
>functions, right?
> On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
impo
>rted.
> For functions, if you don't apply the optimization at compile time,
the linker will just generate a single instruction thunk instead.
>  
> That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
> The loader only patches pointers, one per import if you build your
.dll correctly, it doesn't patch instructions or code strewn throughout
a .d
>ll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
>  
> That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
>  
> pointer to msvcrt!fopen
> pointer to msvcrt!fclose
> null
> pointer to kernel32!Sleep
>  
> But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need
not be adjacent.
>  
> So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Fo
>o.
> But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
> That doesn't work for data though. There's no ability to intervenve
like that.
> So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be importe
>d.
> Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
> And for this reason, I HOPE Modula-3 never imports/exports data.
>  
> Oh, you could, for data, always reference the pointer __imp_Foo, and
if non materializes, create one.
> However that would suck perf in order to make an uncommon case work.
> I hope Modula-3 doesn't do that either. :)
> Though I guess since this global data in question...maybe it is
rare???
>  
> Later,
>  - Jay
>
>
>  
>---------------------------------
> 
> > From: hosking at cs.purdue.edu 
>> Date: Sat, 19 Jan 2008 03:09:47 -0500
>> To: rcoleburn at scires.com 
>> CC: m3devel at elegosoft.com 
>> Subject: Re: [M3devel] pixmap problem
>> 
>> Looks fine to me on I386_DARWIN.
>> 
>> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
>> 
>> > <TestPixmap.zip>
>> 
>
>
>
>---------------------------------
>Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out.
>
>       
>---------------------------------
>
>Web Revelaci*n Yahoo! 2007:
> Premio Favorita del P*blico - íVota tu preferida!
>--0-1095273535-1200761640=:77597
>Content-Type: text/html; charset=iso-8859-1
>Content-Transfer-Encoding: 8bit
>
>Hi:<br>The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu
Gutsy 2.6.22-14-386, 32 bits machine.<br><br>Thanks<br><br><br><b><i>Jay
&l
>t;jayk123 at hotmail.com></i></b> wrote:<blockquote class="replbq"
style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px;
padding-lef
>t: 5px;">   <style> .hmmessage P { margin:0px; padding:0px }
body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } </style> I can
repro the two
> different behaviors on XP.<br> I was going to try on PPC_DARWIN but I
guess Tony's info suffices.<br>  <br> I tried rolling hand.c back
to
> before I changed (months/year ago), since it is involved in bit
twiddling, no change, phew.<br>  <br> Debugging here is a big
humungous&nb
>sp;pain.<br> NT386 has good stacks and line numbers, but no locals or
type info, I'd really sometime like to get Codeview info into those
.objs.
>..I think it is documented well enough, but still not necessarily
easy, or maybe have a C generating backend partly for this
> reason (and to bring up more targets, using native tools), and
function calls in disassembly I think don't resolve; NT386GNU can't yet
bui
>ld this, though it will soon, but I'm not familiar with gdb and there
appears to be no type info. I'm building m3gdb right now, I don't know
if 
>it will work, I hope it has type info, and I'm not familiar with the
relevant code. In gdb I struggle just to view bytes in memory, add
numbers 
>to addresses and see those, etc. I think for MY problem, I'm going to
link in C code to dump the structs. There is tracing code and I enabled
it
>, but even it crashes in Text_Length. At least MY problem crashes,
hopefully near the problem, whereas your problem goes all the way
through to 
>completion with no stopping to hint where the problem is. Darn it. :)
on the mock rudeness and :( on the lack of a crash.<br>  <br> You
wri
>te the bundle out and it matches, so that doesn't rule out bundles as
being the problem? (darn)<br> And bundles look pretty
> simple, a bundle is just a generated source file with a constant in
it.<br> Maybe newline problems? That wouldn't make sense. I just
downl
>oaded some program that might let me separately view the ppm, maybe
it'll reveal something.<br>  <br> The bad behavior has like
regularly s
>paced solid color veritical bars a few pixels side across the whole
picture, and regularly spaced vertical stripes from the correct picture
alte
>rnating with that. Perhaps someone with ppm/bitmap/graphics experience
has seen this behavior and it results from some common pixmap
mismanageme
>nt we could look for?<br>  <br> I have to say this is very
surprising.<br>  <br> I always wondered, and now I pretty much
assume -- Mo
>dula-3 never imports/exports data in its dynamic linking, right? It
alway imports/exports functions, right?<br> On Windows, functions have
an op
>tional optimization, but data must be handled differently at compile
time if it is going to be dynamically imported.<br> For
> functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.<br>
 <br
>> That is, given a symbol Foo, there is a symbol __imp__<font
face="">Foo</font> that is a pointer to the actual foo in another
.dll/.so.<br> Th
>e loader only patches pointers, one per import if you build your
.dll correctly, it doesn't patch instructions or code strewn throughout
a 
>.dll, just one contiguous array of pointers. MAYBE they don't have to
be contiguous for each .dl you import from.<br>  <br> That is, if
cal
>l msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically
has an array:<br>  <br> pointer to msvcrt!fopen<br> pointer to
msvcrt
>!fclose<br> null<br> pointer to kernel32!Sleep<br>  <br> But
perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be
adjacent
>.<br>  <br> So, going back, my point/question is that, if the
compiler knows the function is imported, it can call
> through __imp__Foo instead of calling Foo.<br> But if it calls Foo
and you import Foo, the linker will create the function Foo that just
jmps t
>hrough __imp__Foo.<br> That doesn't work for data though. There's no
ability to intervenve like that.<br> So for imported data, the compiler
mus
>t generated a read and dereference of the pointer __imp__<font
face="">Foo for accesses to Foo, if Foo is to be imported.</font><br>
Data import
>s may be faster when appropriate, but for this reason, I'd say they
aren't worth it.<br> And for this reason, I HOPE Modula-3 never
imports/expo
>rts data.<br>  <br> Oh, you could, for data, always reference the
pointer __imp_Foo, and if non materializes, create one.<br> However that

>would suck perf in order to make an uncommon case work.<br> I hope
Modula-3 doesn't do that either. :)<br> Though I guess since this global
data
> in question...maybe it is rare???<br>  <br> Later,<br>  -
Jay<br><br><br>  <hr id="stopSpelling"> <br> > From:
> hosking at cs.purdue.edu<br>> Date: Sat, 19 Jan 2008 03:09:47
-0500<br>> To: rcoleburn at scires.com<br>> CC:
m3devel at elegosoft.com<br>> 
>Subject: Re: [M3devel] pixmap problem<br>> <br>> Looks fine to
me on I386_DARWIN.<br>> <br>> On Jan 19, 2008, at 12:31 AM, Randy
Col
>eburn wrote:<br>> <br>> > <TestPixmap.zip><br>>
<br><br><br><hr>Need to know the score, the latest news, or you need
your Hotm
>ail*-get your "fix" <a href="http://www.msnmobilefix.com/Default.aspx"
target="_new">Check it out.</a></blockquote><br><p> 
>
>
>      <hr size=1><br><font face="Verdana" size="-2">Web Revelaci*n
Yahoo! 2007:<br> Premio Favorita del P*blico - <a
href="http://es.promotions.ya
>hoo.com/revelacion2007/favoritos/">íVota tu preferida!</a></font>
>--0-1095273535-1200761640=:77597--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080120/d9008e2e/attachment-0002.html>

More information about the M3devel mailing list