foundry27 : Post

Forum Topic - Windows versus QNX6: (12 Items)

View: as

Mario Charest

05/14/2008 4:03 PM

post8062

I have a project sitting on a QNX6 box. I can build it either from QNX6 or from the IDE hosted on Windows, mix the two.
The QNX6 disk is mounted via smbd, and I got Eclipse 4.5 setup to point to the project on the QNX6 box. Everything
is based on custom makefiles. Because make is launches from the same set of files the compiler/linker options are
identical in both cases.

Now the problem is that the executable generated from QNX6 and Windows are of different size and by a lot. We are
talking 90K difference ( on a 200k executable) once striped the difference goes down to 14K which is still a lot.

From what I can gather the Windows version seems to pull out more stuff from libgcc.a then the QNX setup does.

The following is some stuff is a small sample of entries I see in the map file generated by the Windows host that are
not QNX host:

C:/QNX632/host/win32/x86/usr/lib/gcc-lib/i386-pc-nto-qnx6.3.0/3.3.5/libgcc.a(unwind-dw2-fde.o)
C:/QNX632/host/win32/x86/usr/lib/gcc-lib/i386-pc-nto-qnx6.3.0/3.3.5/libgcc.a(unwind-dw2.o)
(_Unwind_Find_FDE)

...

.text 0x080676f0 0x164c C:/QNX632/host/win32/x86/usr/lib/gcc-lib/i386-pc-nto-qnx6.3.0/3.3.5/libgcc.a(unwind
-dw2.o)
0x08068cb0 _Unwind_GetIP
0x08068b18 _Unwind_Resume_or_Rethrow
0x080678ec _Unwind_GetRegionStart
0x08068bf4 _Unwind_Backtrace
...

I have attached the two mapfiles. Suggestion welcome.

Attachment:

map.tgz 26.59 KB

Colin Burgess(deleted)

Re: Windows versus QNX6

Colin Burgess(deleted)

05/14/2008 4:22 PM

post8066

Re: Windows versus QNX6

Hi Mario,

It would appear that _Unwind_Resume was found by the linker in one of the
shared objects,
whereas under windows it wasn't, so it was pulled into the executable.

Now which one was it found in, and why the difference?!!

Mario Charest wrote:
> I have a project sitting on a QNX6 box.  I can build it either from QNX6 
> or from the IDE hosted on Windows, mix the two.   The QNX6 disk is 
> mounted via smbd, and I got Eclipse 4.5 setup to point to the project on 
> the QNX6 box.  Everything is based on custom makefiles.   Because make 
> is launches from the same set of files the compiler/linker options are 
> identical in both cases.
> 
> Now the problem is that the executable generated from QNX6 and Windows 
> are of different size and by a lot.  We are talking 90K difference ( on 
> a 200k executable) once striped the difference goes down to 14K which is 
> still a lot.
> 
>  From what I can gather the Windows version seems to pull out more stuff 
> from libgcc.a then the QNX setup does.
> 
> The following is some stuff is a small sample of entries I see in the 
> map file generated by the Windows host that are not QNX host:
> 
>
C:/QNX632/host/win32/x86/usr/lib/gcc-lib/i386-pc-nto-qnx6.3.0/3.3.5/libgcc.a
(unwind-dw2-fde.o) 
> 
>                               
>
C:/QNX632/host/win32/x86/usr/lib/gcc-lib/i386-pc-nto-qnx6.3.0/3.3.5/libgcc.a
(unwind-dw2.o) 
> (_Unwind_Find_FDE)
> 
> ...
> 
>
C:/QNX632/host/win32/x86/usr/lib/gcc-lib/i386-pc-nto-qnx6.3.0/3.3.5/libgcc.a
(unwind-dw2-fde.o) 
> 
>                               
>
C:/QNX632/host/win32/x86/usr/lib/gcc-lib/i386-pc-nto-qnx6.3.0/3.3.5/libgcc.a
(unwind-dw2.o) 
> (_Unwind_Find_FDE)
> 
> ...
> 
> .text          0x080676f0     0x164c 
>
C:/QNX632/host/win32/x86/usr/lib/gcc-lib/i386-pc-nto-qnx6.3.0/3.3.5/libgcc.a
(unwind-dw2.o)
> 
>                 0x08068cb0                _Unwind_GetIP
>                 0x08068b18                _Unwind_Resume_or_Rethrow
>                 0x080678ec                _Unwind_GetRegionStart
>                 0x08068bf4                _Unwind_Backtrace
> ...
> 
> 
> I have attached the two mapfiles.  Suggestion welcome.
> 
> 
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post8062
> 

-- 
cburgess@qnx.com

Ryan Mansfield(deleted)

Re: Windows versus QNX6

Ryan Mansfield(deleted)

05/14/2008 4:29 PM

post8067

Re: Windows versus QNX6

I remember investigating this size difference a while back. If I recall correctly, what happened was that 3.3.5 on 
Neutrino was configured against a different set of binutils (the build machine's native 2.10 binutils as opposed to the 
2.12 available in SP2 and newer) than the Windows hosted gcc. The misconfigure meant that the Neutrino compiler was 
configured without HAVE_AS_LEB128 support. This meant that gcc would generate different exception handling code on 
Windows than on Neutrino.

Regards,

Ryan Mansfield

Colin Burgess(deleted)

Re: Windows versus QNX6

Colin Burgess(deleted)

05/14/2008 5:00 PM

post8069

Re: Windows versus QNX6

*JOY* :-|

Ryan Mansfield wrote:
> I remember investigating this size difference a while back. If I recall 
> correctly, what happened was that 3.3.5 on Neutrino was configured 
> against a different set of binutils (the build machine's native 2.10 
> binutils as opposed to the 2.12 available in SP2 and newer) than the 
> Windows hosted gcc. The misconfigure meant that the Neutrino compiler 
> was configured without HAVE_AS_LEB128 support. This meant that gcc would 
> generate different exception handling code on Windows than on Neutrino.
> 
> Regards,
> 
> Ryan Mansfield 
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post8067
> 

-- 
cburgess@qnx.com

Mario Charest

Re: Windows versus QNX6

Mario Charest

05/15/2008 8:29 AM

post8085

Re: Windows versus QNX6

> I remember investigating this size difference a while back. If I recall 
> correctly, what happened was that 3.3.5 on Neutrino was configured against a 
> different set of binutils (the build machine's native 2.10 binutils as opposed
>  to the 2.12 available in SP2 and newer) than the Windows hosted gcc. The 
> misconfigure meant that the Neutrino compiler was configured without 
> HAVE_AS_LEB128 support. This meant that gcc would generate different exception
>  handling code on Windows than on Neutrino.
> 
> Regards,
> 
> Ryan Mansfield  


The only fix to that will be 6.4?  I mean not being able to generate the same executable whatever the host platfrom is 
problematic. 

Does that affect debugging with gdb; how will a binary build on QNX4 behave when debugged under Windows and vice versa?

Aleksandar Ristovski(deleted)

Re: Windows versus QNX6

Aleksandar Ristovski(deleted)

05/15/2008 9:15 AM

post8099

Re: Windows versus QNX6

Mario Charest wrote:
>> I remember investigating this size difference a while back. If I recall 
>> correctly, what happened was that 3.3.5 on Neutrino was configured against a 
>> different set of binutils (the build machine's native 2.10 binutils as opposed
>>  to the 2.12 available in SP2 and newer) than the Windows hosted gcc. The 
>> misconfigure meant that the Neutrino compiler was configured without 
>> HAVE_AS_LEB128 support. This meant that gcc would generate different exception
>>  handling code on Windows than on Neutrino.
>>
>> Regards,
>>
>> Ryan Mansfield  
> 
> 
> The only fix to that will be 6.4?  I mean not being able to generate the same executable whatever the host platfrom is
 problematic. 
> 
> Does that affect debugging with gdb; how will a binary build on QNX4 behave when debugged under Windows and vice versa
?

When it comes to binary size difference, it should not affect debugging with gdb, gdb should "understand" both. 

It is different question whether our debugging protocol was the same on qnx4 as it is on Neutrino, and I don't know the 
answer.

Colin Burgess(deleted)

05/15/2008 9:30 AM

post8102

Re: Windows versus QNX6

He mis-typed, he meant QNX6 :-)

Aleksandar Ristovski wrote:
> Mario Charest wrote:
>  >> I remember investigating this size difference a while back. If I
recall
>  >> correctly, what happened was that 3.3.5 on Neutrino was configured 
> against a
>  >> different set of binutils (the build machine's native 2.10 binutils 
> as opposed
>  >>  to the 2.12 available in SP2 and newer) than the Windows hosted 
> gcc. The
>  >> misconfigure meant that the Neutrino compiler was configured without
>  >> HAVE_AS_LEB128 support. This meant that gcc would generate different 
> exception
>  >>  handling code on Windows than on Neutrino.
>  >>
>  >> Regards,
>  >>
>  >> Ryan Mansfield 
>  >
>  >
>  > The only fix to that will be 6.4?  I mean not being able to generate 
> the same executable whatever the host platfrom is problematic.
> 
>  >
>  > Does that affect debugging with gdb; how will a binary build on QNX4 
> behave when debugged under Windows and vice versa?
> 
> When it comes to binary size difference, it should not affect debugging 
> with gdb, gdb should "understand" both.
> 
> It is different question whether our debugging protocol was the same on 
> qnx4 as it is on Neutrino, and I don't know the answer.
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post8099
> 

-- 
cburgess@qnx.com

Steve Reid

05/15/2008 9:37 AM

post8103

RE: Windows versus QNX6

That would be QNX Neutrino. :-)


Steve Reid (stever@qnx.com)
Technical Editor
QNX Software Systems 
 

> -----Original Message-----
> From: Colin Burgess [mailto:cburgess@qnx.com] 
> Sent: Thursday, May 15, 2008 9:31 AM
> To: general-toolchain
> Subject: Re: Windows versus QNX6
> 
> He mis-typed, he meant QNX6 :-)

Colin Burgess(deleted)

05/15/2008 9:40 AM

post8104

Re: Windows versus QNX6

Argh, I'm just going to say !QNX4 from now on.. :-)

Steve Reid wrote:
> That would be QNX Neutrino. :-)
> 
> 
> Steve Reid (stever@qnx.com)
> Technical Editor
> QNX Software Systems
>  
> 
>  > -----Original Message-----
>  > From: Colin Burgess [mailto:cburgess@qnx.com]
>  > Sent: Thursday, May 15, 2008 9:31 AM
>  > To: general-toolchain
>  > Subject: Re: Windows versus QNX6
>  >
>  > He mis-typed, he meant QNX6 :-)
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post8103
> 

-- 
cburgess@qnx.com

Ryan Mansfield(deleted)

Re: Windows versus QNX6

Ryan Mansfield(deleted)

05/15/2008 9:43 AM

post8105

Re: Windows versus QNX6

> The only fix to that will be 6.4?  I mean not being able to generate the same 
> executable whatever the host platfrom is problematic. 

We don't have another release planned with gcc 3.3.5 so the next available fix would be with gcc 4.2 in QNX 6.4. If the 
problem is critical for you, you should  go through the official support channels and get a PSP fix for this issue. 

Regards,

Ryan Mansfield

Mario Charest

05/15/2008 9:57 AM

post8108

Re: Windows versus QNX6

> > The only fix to that will be 6.4?  I mean not being able to generate the 
> same 
> > executable whatever the host platfrom is problematic. 
> 
> We don't have another release planned with gcc 3.3.5 so the next available fix
>  would be with gcc 4.2 in QNX 6.4. If the problem is critical for you, you 
> should  go through the official support channels and get a PSP fix for this 
> issue. 

Ok thanks.  I'm surprise this is critical only to me ;-)

> 
> Regards,
> 
> Ryan Mansfield
> 
>

Ryan Mansfield(deleted)

05/15/2008 10:24 AM

post8111

Re: Windows versus QNX6

> > > The only fix to that will be 6.4?  I mean not being able to generate the 
> > same 
> > > executable whatever the host platfrom is problematic. 
> > 
> > We don't have another release planned with gcc 3.3.5 so the next available 
> fix
> >  would be with gcc 4.2 in QNX 6.4. If the problem is critical for you, you 
> > should  go through the official support channels and get a PSP fix for this 
> 
> > issue. 
> 
> Ok thanks.  I'm surprise this is critical only to me ;-)

I think you're the first customer to report it, or at least there are no customer flagged PRs about this problem. 

Regards,

Ryan Mansfield

Return

The text you entered is not a valid object ID
More Information
Object IDs begin with an object prefix and end with a number. For example, if you enter
artf2345
the application will jump directly to an artifact with the ID artf2345. Some valid object prefixes are:
artf	for an artifact
doc	for a document
page	for a project page
topc	for a discussion topic
wiki	for a wiki page