GCC 4.3.2 Update

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

GCC 4.3.2 Update

Paul Smedley-5
Hi Guys,

Sorry it's been such a long time between drinks here, but I think I'm
finally getting close to a fresh release.

I've spent a lot of time trying to debug why seamonkey dies in
necko.dll to no avail.  So I decided to revamp emx.* based on the
latest winnt.* rather than trying to keep hacking the old versions.
{winnt.c changed significantly between GCC 4.2.4 and 4.3.2 }

Finally, it seems that I may be making progress - currently trying a
Seamonkey build and:
Directory of U:\dev\mozilla\mozilla\obj\dist\bin\components

 6/01/09  8:52        608,462     54 a---  necko.dll
        1 file(s)     608,462 bytes used

So things may be looking up.

Of course, with such radical changes, there's every possibility that I
broke something in the process, so I need to do some more testing
before I upload a binary.  Of course, I'd also like seamonkey to
complete building which I'll know in an hour or so :)

--
Cheers,

Paul.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

William L. Hartzell-2
Sir:
Paul Smedley wrote:

> Hi Guys,
>
> Sorry it's been such a long time between drinks here, but I think I'm
> finally getting close to a fresh release.
>
> I've spent a lot of time trying to debug why seamonkey dies in
> necko.dll to no avail.  So I decided to revamp emx.* based on the
> latest winnt.* rather than trying to keep hacking the old versions.
> {winnt.c changed significantly between GCC 4.2.4 and 4.3.2 }
>
> Finally, it seems that I may be making progress - currently trying a
> Seamonkey build and:
> Directory of U:\dev\mozilla\mozilla\obj\dist\bin\components
>
>  6/01/09  8:52        608,462     54 a---  necko.dll
>         1 file(s)     608,462 bytes used
>
> So things may be looking up.
>
> Of course, with such radical changes, there's every possibility that I
> broke something in the process, so I need to do some more testing
> before I upload a binary.  Of course, I'd also like seamonkey to
> complete building which I'll know in an hour or so :)
>

Thanks to you.  Hears to awaiting for good news.
--
Bill
<Thanks, a Million>
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Paul Smedley-5
In reply to this post by Paul Smedley-5
Hi All,

On Mon, 5 Jan 2009 22:51:00 UTC, "Paul Smedley"
<[hidden email]> wrote:

> Hi Guys,
>
> Sorry it's been such a long time between drinks here, but I think I'm
> finally getting close to a fresh release.
>
> I've spent a lot of time trying to debug why seamonkey dies in
> necko.dll to no avail.  So I decided to revamp emx.* based on the
> latest winnt.* rather than trying to keep hacking the old versions.
> {winnt.c changed significantly between GCC 4.2.4 and 4.3.2 }
>
> Finally, it seems that I may be making progress - currently trying a
> Seamonkey build and:
> Directory of U:\dev\mozilla\mozilla\obj\dist\bin\components
>
>  6/01/09  8:52        608,462     54 a---  necko.dll
>         1 file(s)     608,462 bytes used
>
> So things may be looking up.
>
> Of course, with such radical changes, there's every possibility that I
> broke something in the process, so I need to do some more testing
> before I upload a binary.  Of course, I'd also like seamonkey to
> complete building which I'll know in an hour or so :)

Quick update - a new SIGSEGV to debug:
[U:\DEV\MOZILLA\MOZILLA\obj\nss]U:\DEV\MOZILLA\MOZILLA\OBJ\NSS\shlibsi
gn -v -i U:/dev/mozilla/mozilla/obj/dist/lib/softokn3.DLL

Killed by SIGSEGV
pid=0x2a42 ppid=0x2a41 tid=0x0001 slot=0x013b pri=0x0200 mc=0x0001
U:\DEV\MOZILLA\MOZILLA\OBJ\NSS\SHLIBSIGN.EXE
cs:eip=005b:c9e58955      ss:esp=0053:0011fc2c      ebp=0011fc58
 ds=0053      es=0053      fs=150b      gs=0000     efl=00010212
eax=0011ff71 ebx=0011ff5c ecx=00000000 edx=0011ff71 edi=000100e1
esi=00000004
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.


--
Cheers,

Paul.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Paul Smedley-5
Hi All,

On Tue, 6 Jan 2009 01:11:28 UTC, "Paul Smedley"
<[hidden email]> wrote:

> Hi All,
>
> On Mon, 5 Jan 2009 22:51:00 UTC, "Paul Smedley"
> <[hidden email]> wrote:
>
> > Hi Guys,
> >
> > Sorry it's been such a long time between drinks here, but I think I'm
> > finally getting close to a fresh release.
> >
> > I've spent a lot of time trying to debug why seamonkey dies in
> > necko.dll to no avail.  So I decided to revamp emx.* based on the
> > latest winnt.* rather than trying to keep hacking the old versions.
> > {winnt.c changed significantly between GCC 4.2.4 and 4.3.2 }
> >
> > Finally, it seems that I may be making progress - currently trying a
> > Seamonkey build and:
> > Directory of U:\dev\mozilla\mozilla\obj\dist\bin\components
> >
> >  6/01/09  8:52        608,462     54 a---  necko.dll
> >         1 file(s)     608,462 bytes used
> >
> > So things may be looking up.
> >
> > Of course, with such radical changes, there's every possibility that I
> > broke something in the process, so I need to do some more testing
> > before I upload a binary.  Of course, I'd also like seamonkey to
> > complete building which I'll know in an hour or so :)
>
> Quick update - a new SIGSEGV to debug:
> [U:\DEV\MOZILLA\MOZILLA\obj\nss]U:\DEV\MOZILLA\MOZILLA\OBJ\NSS\shlibsi
> gn -v -i U:/dev/mozilla/mozilla/obj/dist/lib/softokn3.DLL
>
> Killed by SIGSEGV
> pid=0x2a42 ppid=0x2a41 tid=0x0001 slot=0x013b pri=0x0200 mc=0x0001
> U:\DEV\MOZILLA\MOZILLA\OBJ\NSS\SHLIBSIGN.EXE
> cs:eip=005b:c9e58955      ss:esp=0053:0011fc2c      ebp=0011fc58
>  ds=0053      es=0053      fs=150b      gs=0000     efl=00010212
> eax=0011ff71 ebx=0011ff5c ecx=00000000 edx=0011ff71 edi=000100e1
> esi=00000004
> Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

Looks like a problem in DLL creation when dllimport/dllexport are
used:
ie
 6/01/09 15:55         28,017     54 a---  plc4.dll.bad
 6/01/09 13:43         27,989     54 a---  plc4.dll.good

plc4.dll.good is built with a November build of GCC 4.3.2 and is good
plc4.dll.bad is slightly larger (28 bytes) and built with a January
build and is bad - now to work out what bytes are different and fix it
:)

--
Cheers,

Paul.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Paul Smedley-5
Hi All,

On Tue, 6 Jan 2009 06:29:03 UTC, "Paul Smedley"
<[hidden email]> wrote:

> Hi All,
>
> On Tue, 6 Jan 2009 01:11:28 UTC, "Paul Smedley"
> <[hidden email]> wrote:
>
> > Hi All,
> >
> > On Mon, 5 Jan 2009 22:51:00 UTC, "Paul Smedley"
> > <[hidden email]> wrote:
> >
> > > Hi Guys,
> > >
> > > Sorry it's been such a long time between drinks here, but I think I'm
> > > finally getting close to a fresh release.
> > >
> > > I've spent a lot of time trying to debug why seamonkey dies in
> > > necko.dll to no avail.  So I decided to revamp emx.* based on the
> > > latest winnt.* rather than trying to keep hacking the old versions.
> > > {winnt.c changed significantly between GCC 4.2.4 and 4.3.2 }
> > >
> > > Finally, it seems that I may be making progress - currently trying a
> > > Seamonkey build and:
> > > Directory of U:\dev\mozilla\mozilla\obj\dist\bin\components
> > >
> > >  6/01/09  8:52        608,462     54 a---  necko.dll
> > >         1 file(s)     608,462 bytes used
> > >
> > > So things may be looking up.
> > >
> > > Of course, with such radical changes, there's every possibility that I
> > > broke something in the process, so I need to do some more testing
> > > before I upload a binary.  Of course, I'd also like seamonkey to
> > > complete building which I'll know in an hour or so :)
> >
> > Quick update - a new SIGSEGV to debug:
> > [U:\DEV\MOZILLA\MOZILLA\obj\nss]U:\DEV\MOZILLA\MOZILLA\OBJ\NSS\shlibsi
> > gn -v -i U:/dev/mozilla/mozilla/obj/dist/lib/softokn3.DLL
> >
> > Killed by SIGSEGV
> > pid=0x2a42 ppid=0x2a41 tid=0x0001 slot=0x013b pri=0x0200 mc=0x0001
> > U:\DEV\MOZILLA\MOZILLA\OBJ\NSS\SHLIBSIGN.EXE
> > cs:eip=005b:c9e58955      ss:esp=0053:0011fc2c      ebp=0011fc58
> >  ds=0053      es=0053      fs=150b      gs=0000     efl=00010212
> > eax=0011ff71 ebx=0011ff5c ecx=00000000 edx=0011ff71 edi=000100e1
> > esi=00000004
> > Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
>
> Looks like a problem in DLL creation when dllimport/dllexport are
> used:
> ie
>  6/01/09 15:55         28,017     54 a---  plc4.dll.bad
>  6/01/09 13:43         27,989     54 a---  plc4.dll.good
>
> plc4.dll.good is built with a November build of GCC 4.3.2 and is good
> plc4.dll.bad is slightly larger (28 bytes) and built with a January
> build and is bad - now to work out what bytes are different and fix it
> :)

Still no progress... I have been able to determine the following:

Three object files that make up plc4.dll end up a larger size with my
latest gcc 4.3.2 build (base64.o +19 bytes), (plerror.o +12 bytes), &
(plgetopt.o +12 bytes), however, I played around with a plc4.dll with
small/large versions of these object files and only plgetopt.o made a
difference.

I don't understand what's contributing to the larger file though :(  
If anyone has some clues on how to investigate the differences with
the .o files I'm welcome to any suggestions!

--
Cheers,

Paul.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Dave Yeo-3
On 01/10/09 03:38 pm, Paul Smedley wrote:

> Still no progress... I have been able to determine the following:
>
> Three object files that make up plc4.dll end up a larger size with my
> latest gcc 4.3.2 build (base64.o +19 bytes), (plerror.o +12 bytes),&
> (plgetopt.o +12 bytes), however, I played around with a plc4.dll with
> small/large versions of these object files and only plgetopt.o made a
> difference.
>
> I don't understand what's contributing to the larger file though:(
> If anyone has some clues on how to investigate the differences with
> the .o files I'm welcome to any suggestions!
>

Have you tried compiling with CFLAGS=-S (and also separately -E) and
diffing the assembler (and preprocessor) output?
Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Dave Yeo-3
In reply to this post by Paul Smedley-5
On 01/10/09 03:38 pm, Paul Smedley wrote:

> Still no progress... I have been able to determine the following:
>
> Three object files that make up plc4.dll end up a larger size with my
> latest gcc 4.3.2 build (base64.o +19 bytes), (plerror.o +12 bytes),&
> (plgetopt.o +12 bytes), however, I played around with a plc4.dll with
> small/large versions of these object files and only plgetopt.o made a
> difference.
>
> I don't understand what's contributing to the larger file though:(
> If anyone has some clues on how to investigate the differences with
> the .o files I'm welcome to any suggestions!
>

I could of sworn I posted this already but it didn't show up here.
Have you tried adding CFLAGS -S then diffing the assembler output?
Perhaps also CFLAGS -E to compare the preprocessor output as well.
Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Paul Smedley-5
Hi Dave,

On Sun, 11 Jan 2009 05:59:30 UTC, Dave Yeo <[hidden email]>
wrote:

> On 01/10/09 03:38 pm, Paul Smedley wrote:
> > Still no progress... I have been able to determine the following:
> >
> > Three object files that make up plc4.dll end up a larger size with my
> > latest gcc 4.3.2 build (base64.o +19 bytes), (plerror.o +12 bytes),&
> > (plgetopt.o +12 bytes), however, I played around with a plc4.dll with
> > small/large versions of these object files and only plgetopt.o made a
> > difference.
> >
> > I don't understand what's contributing to the larger file though:(
> > If anyone has some clues on how to investigate the differences with
> > the .o files I'm welcome to any suggestions!
> >
>
> I could of sworn I posted this already but it didn't show up here.
> Have you tried adding CFLAGS -S then diffing the assembler output?
> Perhaps also CFLAGS -E to compare the preprocessor output as well.

I've looked at -E - but hadn't looked at -S - I'm still learning these
switches!

Thanks for the tip, I'll take a look tomorrow!

--
Cheers,

Paul.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Paul Smedley-5
Hi All,

On Sun, 11 Jan 2009 09:02:04 UTC, "Paul Smedley"
<[hidden email]> wrote:

> Hi Dave,
>
> On Sun, 11 Jan 2009 05:59:30 UTC, Dave Yeo <[hidden email]>
> wrote:
>
> > On 01/10/09 03:38 pm, Paul Smedley wrote:
> > > Still no progress... I have been able to determine the following:
> > >
> > > Three object files that make up plc4.dll end up a larger size with my
> > > latest gcc 4.3.2 build (base64.o +19 bytes), (plerror.o +12 bytes),&
> > > (plgetopt.o +12 bytes), however, I played around with a plc4.dll with
> > > small/large versions of these object files and only plgetopt.o made a
> > > difference.
> > >
> > > I don't understand what's contributing to the larger file though:(
> > > If anyone has some clues on how to investigate the differences with
> > > the .o files I'm welcome to any suggestions!
> > >
> >
> > I could of sworn I posted this already but it didn't show up here.
> > Have you tried adding CFLAGS -S then diffing the assembler output?
> > Perhaps also CFLAGS -E to compare the preprocessor output as well.
>
> I've looked at -E - but hadn't looked at -S - I'm still learning these
> switches!
>
> Thanks for the tip, I'll take a look tomorrow!

For info - http://smedley.info/plgetopt.zip - preprocessor output is
identical - investigating assembler differences now.  File naming
nomenclature per below:
plgetopt.o.asm.bad Assembler output (-S) fron non-working plgetopt
plgetopt.o.asm.good Assembler output (-S) fron working plgetopt
plgetopt.o.bad Object file from non-working plgetopt
plgetopt.o.good Object file from working plgetopt
plgetopt.o.pp.bad Preprocessor output (-E) from non-working plgetopt
plgetopt.o.pp.good Preprocessor output (-E) from working plgetopt

--
Cheers,

Paul.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Paul Smedley-5
Hi Again,

On Tue, 13 Jan 2009 04:53:29 UTC, "Paul Smedley"
<[hidden email]> wrote:

> Hi All,
>
> On Sun, 11 Jan 2009 09:02:04 UTC, "Paul Smedley"
> <[hidden email]> wrote:
>
> > Hi Dave,
> >
> > On Sun, 11 Jan 2009 05:59:30 UTC, Dave Yeo <[hidden email]>
> > wrote:
> >
> > > On 01/10/09 03:38 pm, Paul Smedley wrote:
> > > > Still no progress... I have been able to determine the following:
> > > >
> > > > Three object files that make up plc4.dll end up a larger size with my
> > > > latest gcc 4.3.2 build (base64.o +19 bytes), (plerror.o +12 bytes),&
> > > > (plgetopt.o +12 bytes), however, I played around with a plc4.dll with
> > > > small/large versions of these object files and only plgetopt.o made a
> > > > difference.
> > > >
> > > > I don't understand what's contributing to the larger file though:(
> > > > If anyone has some clues on how to investigate the differences with
> > > > the .o files I'm welcome to any suggestions!
> > > >
> > >
> > > I could of sworn I posted this already but it didn't show up here.
> > > Have you tried adding CFLAGS -S then diffing the assembler output?
> > > Perhaps also CFLAGS -E to compare the preprocessor output as well.
> >
> > I've looked at -E - but hadn't looked at -S - I'm still learning these
> > switches!
> >
> > Thanks for the tip, I'll take a look tomorrow!
>
> For info - http://smedley.info/plgetopt.zip - preprocessor output is
> identical - investigating assembler differences now.  File naming
> nomenclature per below:
> plgetopt.o.asm.bad Assembler output (-S) fron non-working plgetopt
> plgetopt.o.asm.good Assembler output (-S) fron working plgetopt
> plgetopt.o.bad Object file from non-working plgetopt
> plgetopt.o.good Object file from working plgetopt
> plgetopt.o.pp.bad Preprocessor output (-E) from non-working plgetopt
> plgetopt.o.pp.good Preprocessor output (-E) from working plgetopt

... and the initial obvious 'difference' is teh decoration of many
symbols with a leading * - now to work out why.....


--
Cheers,

Paul.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Peter Weilbacher
On 13.01.09 09:05, Paul Smedley wrote:

>> For info - http://smedley.info/plgetopt.zip - preprocessor output is
>> identical - investigating assembler differences now.  File naming
>> nomenclature per below:
>> plgetopt.o.asm.bad Assembler output (-S) fron non-working plgetopt
>> plgetopt.o.asm.good Assembler output (-S) fron working plgetopt
>> plgetopt.o.bad Object file from non-working plgetopt
>> plgetopt.o.good Object file from working plgetopt
>> plgetopt.o.pp.bad Preprocessor output (-E) from non-working plgetopt
>> plgetopt.o.pp.good Preprocessor output (-E) from working plgetopt
>
> ... and the initial obvious 'difference' is teh decoration of many
> symbols with a leading * - now to work out why.....

The difference between the assembler files is also in the
_PL_DestroyOptState function. But I don't really understand all the
differences (never really had the time to get into assembler, what the
heck is "leal"?).
--
Please     | Official Warpzilla Ports: http://www.mozilla.org/ports/os2/
reply in   |
newsgroup  |          Enhanced OS/2 builds: http://pmw-warpzilla.sf.net/
     Steve's Warpzilla Tips: http://www.os2bbs.com/os2news/Warpzilla.html
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Dave Yeo-3
On 01/13/09 11:42 am, Peter Weilbacher wrote:

> On 13.01.09 09:05, Paul Smedley wrote:
>>> For info - http://smedley.info/plgetopt.zip - preprocessor output is
>>> identical - investigating assembler differences now. File naming
>>> nomenclature per below:
>>> plgetopt.o.asm.bad Assembler output (-S) fron non-working plgetopt
>>> plgetopt.o.asm.good Assembler output (-S) fron working plgetopt
>>> plgetopt.o.bad Object file from non-working plgetopt
>>> plgetopt.o.good Object file from working plgetopt
>>> plgetopt.o.pp.bad Preprocessor output (-E) from non-working plgetopt
>>> plgetopt.o.pp.good Preprocessor output (-E) from working plgetopt
>>
>> ... and the initial obvious 'difference' is teh decoration of many
>> symbols with a leading * - now to work out why.....
>
> The difference between the assembler files is also in the
> _PL_DestroyOptState function. But I don't really understand all the
> differences (never really had the time to get into assembler, what the
> heck is "leal"?).

load effective address long. I looked it up last night. What I couldn't
easily find was anything about addressing. I'd assume that the * is a
different addressing symbol in which case no wonder it crashed. Still
i386 assembler has so many suffixes, prefixes etc that really somebody
knowledgeable needs to look at it. I'd suggest perhaps posting on the
klibc list.
Dave
Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Paul Smedley-5
Hi Dave,

On Tue, 13 Jan 2009 20:46:44 UTC, Dave Yeo <[hidden email]>
wrote:

> On 01/13/09 11:42 am, Peter Weilbacher wrote:
> > On 13.01.09 09:05, Paul Smedley wrote:
> >>> For info - http://smedley.info/plgetopt.zip - preprocessor output is
> >>> identical - investigating assembler differences now. File naming
> >>> nomenclature per below:
> >>> plgetopt.o.asm.bad Assembler output (-S) fron non-working plgetopt
> >>> plgetopt.o.asm.good Assembler output (-S) fron working plgetopt
> >>> plgetopt.o.bad Object file from non-working plgetopt
> >>> plgetopt.o.good Object file from working plgetopt
> >>> plgetopt.o.pp.bad Preprocessor output (-E) from non-working plgetopt
> >>> plgetopt.o.pp.good Preprocessor output (-E) from working plgetopt
> >>
> >> ... and the initial obvious 'difference' is teh decoration of many
> >> symbols with a leading * - now to work out why.....
> >
> > The difference between the assembler files is also in the
> > _PL_DestroyOptState function. But I don't really understand all the
> > differences (never really had the time to get into assembler, what the
> > heck is "leal"?).
>
> load effective address long. I looked it up last night. What I couldn't
> easily find was anything about addressing. I'd assume that the * is a
> different addressing symbol in which case no wonder it crashed. Still
> i386 assembler has so many suffixes, prefixes etc that really somebody
> knowledgeable needs to look at it. I'd suggest perhaps posting on the
> klibc list.
Yeah I'll do that if I don't find the answer in the next few days.  
This wasn't happening before updating the emx.c to the latest win32
dllimport/dllexport code - so I'm guessing it's some code in i386.c
that is called only when it detects a dllimport'd symbol - with the
'old' emx.c - nothing was detected as being dllimport'd so the symbols
didn't get mangled....

--
Cheers,

Paul.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Paul Smedley-5
In reply to this post by Dave Yeo-3
Hi Guys,

On Tue, 13 Jan 2009 20:46:44 UTC, Dave Yeo <[hidden email]>
wrote:

> On 01/13/09 11:42 am, Peter Weilbacher wrote:
> > On 13.01.09 09:05, Paul Smedley wrote:
> >>> For info - http://smedley.info/plgetopt.zip - preprocessor output is
> >>> identical - investigating assembler differences now. File naming
> >>> nomenclature per below:
> >>> plgetopt.o.asm.bad Assembler output (-S) fron non-working plgetopt
> >>> plgetopt.o.asm.good Assembler output (-S) fron working plgetopt
> >>> plgetopt.o.bad Object file from non-working plgetopt
> >>> plgetopt.o.good Object file from working plgetopt
> >>> plgetopt.o.pp.bad Preprocessor output (-E) from non-working plgetopt
> >>> plgetopt.o.pp.good Preprocessor output (-E) from working plgetopt
> >>
> >> ... and the initial obvious 'difference' is teh decoration of many
> >> symbols with a leading * - now to work out why.....
> >
> > The difference between the assembler files is also in the
> > _PL_DestroyOptState function. But I don't really understand all the
> > differences (never really had the time to get into assembler, what the
> > heck is "leal"?).
>
> load effective address long. I looked it up last night. What I couldn't
> easily find was anything about addressing. I'd assume that the * is a
> different addressing symbol in which case no wonder it crashed. Still
> i386 assembler has so many suffixes, prefixes etc that really somebody
> knowledgeable needs to look at it. I'd suggest perhaps posting on the
> klibc list.

FWIW I think I found the problem.... at least I can now build a 'good'
plc4.dll

Attempting a seamonkey build now and will advise the result when I
know it :)

--
Cheers,

Paul.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Ilya Zakharevich
In reply to this post by Paul Smedley-5
[A complimentary Cc of this posting was sent to
Paul Smedley
<[hidden email]>], who wrote in article <[hidden email]>:
> > load effective address long. I looked it up last night. What I couldn't
> > easily find was anything about addressing. I'd assume that the * is a
> > different addressing symbol in which case no wonder it crashed. Still
> > i386 assembler has so many suffixes, prefixes etc that really somebody
> > knowledgeable needs to look at it. I'd suggest perhaps posting on the
> > klibc list.

> Yeah I'll do that if I don't find the answer in the next few days.  
> This wasn't happening before updating the emx.c to the latest win32
> dllimport/dllexport code - so I'm guessing it's some code in i386.c
> that is called only when it detects a dllimport'd symbol - with the
> 'old' emx.c - nothing was detected as being dllimport'd so the symbols
> didn't get mangled....

Looks like it is assuming that the function pointer is indirect (as
with Unixish style of dynalinking).  I suppose I saw a similar bug
with vararg functions - but I did not debugged to the end.)

Hope this helps,
Ilya
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Paul Smedley-5
In reply to this post by Paul Smedley-5
Hi All,
On Wed, 14 Jan 2009 08:52:07 UTC, "Paul Smedley"
<[hidden email]> wrote:

> Hi Guys,
>
> On Tue, 13 Jan 2009 20:46:44 UTC, Dave Yeo <[hidden email]>
> wrote:
>
> > On 01/13/09 11:42 am, Peter Weilbacher wrote:
> > > On 13.01.09 09:05, Paul Smedley wrote:
> > >>> For info - http://smedley.info/plgetopt.zip - preprocessor output is
> > >>> identical - investigating assembler differences now. File naming
> > >>> nomenclature per below:
> > >>> plgetopt.o.asm.bad Assembler output (-S) fron non-working plgetopt
> > >>> plgetopt.o.asm.good Assembler output (-S) fron working plgetopt
> > >>> plgetopt.o.bad Object file from non-working plgetopt
> > >>> plgetopt.o.good Object file from working plgetopt
> > >>> plgetopt.o.pp.bad Preprocessor output (-E) from non-working plgetopt
> > >>> plgetopt.o.pp.good Preprocessor output (-E) from working plgetopt
> > >>
> > >> ... and the initial obvious 'difference' is teh decoration of many
> > >> symbols with a leading * - now to work out why.....
> > >
> > > The difference between the assembler files is also in the
> > > _PL_DestroyOptState function. But I don't really understand all the
> > > differences (never really had the time to get into assembler, what the
> > > heck is "leal"?).
> >
> > load effective address long. I looked it up last night. What I couldn't
> > easily find was anything about addressing. I'd assume that the * is a
> > different addressing symbol in which case no wonder it crashed. Still
> > i386 assembler has so many suffixes, prefixes etc that really somebody
> > knowledgeable needs to look at it. I'd suggest perhaps posting on the
> > klibc list.
>
> FWIW I think I found the problem.... at least I can now build a 'good'
> plc4.dll
>
> Attempting a seamonkey build now and will advise the result when I
> know it :)

One step closer at least - build completes now, as does Firefox build
- however both SIGSEGV at startup - so not 100% there yet!

--
Cheers,

Paul.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

David T. Johnson
Paul Smedley wrote:
)
>
> One step closer at least - build completes now, as does Firefox build
> - however both SIGSEGV at startup - so not 100% there yet!
>

On a guess, this is probably a further problem with the difference in
stack frame alignment between Linux and OS/2 for SSE.  Maybe you could
selectively use the force_align_arg_pointer (added in 4.2+) to get a
working SeaMonkey build.


--
Posted with OS/2 Warp 4.52
and Sea Monkey 1.5a
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.3.2 Update

Paul Smedley-5
Hi David,

On Thu, 15 Jan 2009 16:37:37 UTC, "David T. Johnson"
<[hidden email]> wrote:

> Paul Smedley wrote:
> )
> >
> > One step closer at least - build completes now, as does Firefox build
> > - however both SIGSEGV at startup - so not 100% there yet!
> >
>
> On a guess, this is probably a further problem with the difference in
> stack frame alignment between Linux and OS/2 for SSE.  Maybe you could
> selectively use the force_align_arg_pointer (added in 4.2+) to get a
> working SeaMonkey build.

In the end I added some more hacks to i386.c to not execute code for
dllimported symbols on OS/2.  This fixed the sigsegv's :)

--
Cheers,

Paul.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2