|
Mario Charest
11/12/2008 3:31 PM
post16492
|
Using custom makefile that are basicaly identical under Windows and QNX6, the executable name in the ELF file is
different. When build under QNX6 the filename matches the file in ELF, that means if I start the program slay <execname
> will work.
But build under Windows I have to do slay obj/<execname>. I do get around this?
|
|
|
|
|
|
Ryan Mansfield(deleted)
11/12/2008 3:57 PM
post16496
|
Mario Charest wrote:
> Using custom makefile that are basicaly identical under Windows and QNX6, the executable name in the ELF file is
different. When build under QNX6 the filename matches the file in ELF, that means if I start the program slay <execname
> will work.
>
> But build under Windows I have to do slay obj/<execname>. I do get around this?
Are you adding a use message or a stack note to the binary? The problem
is that by default ldrel used to add a debug path note to the binary and
the loader would set the program name using the information provided by
the note. ldrel was modified awhile back not add the debug path by
default. If you build yourself an updated ldrel for 6.3.2 and rebuild
your executable, you should be able to slay it with the proper progname.
Regards,
Ryan Mansfield
|
|
|
|
|
|
Mario Charest
11/12/2008 4:12 PM
post16497
|
-----Original Message-----
From: Ryan Mansfield [mailto:community-noreply@qnx.com]
Sent: November-12-08 3:58 PM
To: general-toolchain
Subject: Re: Executable name
Mario Charest wrote:
> Using custom makefile that are basicaly identical under Windows and QNX6, the executable name in the ELF file is
different. When build under QNX6 the filename matches the file in ELF, that means if I start the program slay <execname
> will work.
>
> But build under Windows I have to do slay obj/<execname>. I do get around this?
Are you adding a use message or a stack note to the binary?
Yes we are adding a use message? I'll check what's it's doing
The problem
is that by default ldrel used to add a debug path note to the binary and
the loader would set the program name using the information provided by
the note. ldrel was modified awhile back not add the debug path by
default. If you build yourself an updated ldrel for 6.3.2 and rebuild
your executable, you should be able to slay it with the proper progname.
Scary ;-) Strange that the self hosted and windows version don't behave the same though.
Regards,
Ryan Mansfield
_______________________________________________
General
http://community.qnx.com/sf/go/post16496
|
|
|
|
|
|
Colin Burgess(deleted)
11/12/2008 4:18 PM
post16498
|
Mario Charest wrote:
>
> -----Original Message-----
> From: Ryan Mansfield [mailto:community-noreply@qnx.com]
> Sent: November-12-08 3:58 PM
> To: general-toolchain
> Subject: Re: Executable name
>
> Mario Charest wrote:
>> Using custom makefile that are basicaly identical under Windows and QNX6, the executable name in the ELF file is
different. When build under QNX6 the filename matches the file in ELF, that means if I start the program slay <execname
> will work.
>>
>> But build under Windows I have to do slay obj/<execname>. I do get around this?
>
> Are you adding a use message or a stack note to the binary?
>
> Yes we are adding a use message? I'll check what's it's doing
>
> The problem
> is that by default ldrel used to add a debug path note to the binary and
> the loader would set the program name using the information provided by
> the note. ldrel was modified awhile back not add the debug path by
> default. If you build yourself an updated ldrel for 6.3.2 and rebuild
> your executable, you should be able to slay it with the proper progname.
>
> Scary ;-) Strange that the self hosted and windows version don't behave the same though.
It is, really. If you do a pidin you should see obj/execname in the native case, and obj\execname in the windows case
(note the backslash)
slay does a basename() on the binary, so slay <execname> will work for the first one. But it fails to realize that
backslash is a directory
seperator, so it fails for the windows version.
The QNT_DEBUG_FULLPATH stuff was done long long ago before anyone ever dreamed of windows hosted development, I suspect,
but was removed in 640, thanksfully.
Colin
> Regards,
>
> Ryan Mansfield
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post16496
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post16497
>
--
cburgess@qnx.com
|
|
|
|
|
|
Thomas Fletcher
11/17/2008 8:18 AM
post16640
|
Colin Burgess wrote:
[ Tales of Windows and QNX binaries reporting different names snippped ]
> The QNT_DEBUG_FULLPATH stuff was done long long ago before anyone
> ever dreamed of windows hosted development, I suspect, but was
> removed in 640, thanksfully.
C'mon .. that's not fair at all =;-) The DEBUG_FULLPATH stuff is
actually there
to provide debuggers with additional intelligence so that users would
have to specify
less 'stuff' . The fact that it never got used (inspired from the
Watcom toolchain is
my understanding of this bit of history) isn't the ELF sections fault =;-)
The _real_ problem has nothing to do with the DEBUG_FULLPATH but rather the
fact that extracting the "name of the thing that was executed" never had
a proper API
in Neutrino so the defacto use of DEBUG_FULLPATH became to use it to
associate
a name with a pid and once that happened ... well we are where we are today.
Thankfully this was all cleaned up and made better in 6.4.0, and though
the name is
wonkey, the behaviour is consistant ... thanks Colin!
Thomas
|
|
|
|
|
|
Mario Charest
11/13/2008 5:47 PM
post16544
|
________________________________________
From: Ryan Mansfield [community-noreply@qnx.com]
Sent: Wednesday, November 12, 2008 3:57 PM
To: general-toolchain
Subject: Re: Executable name
Mario Charest wrote:
> Using custom makefile that are basicaly identical under Windows and QNX6, the executable name in the ELF file is
different. When build under QNX6 the filename matches the file in ELF, that means if I start the program slay <execname
> will work.
>
> But build under Windows I have to do slay obj/<execname>. I do get around this?
If you build yourself an updated ldrel for 6.3.2 and rebuild
your executable, you should be able to slay it with the proper progname.
Since the problem is for Windows how would I go about compiling a version for Windows? I mean it has to be a windows
binary!!!!
Regards,
Ryan Mansfield
_______________________________________________
General
http://community.qnx.com/sf/go/post16496
|
|
|
|
|
|
Colin Burgess(deleted)
11/13/2008 9:33 PM
post16548
|
Ryan isn't the 640 version fixed? Mario you have the 640 release version, right?
-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com]
Sent: Thu 11/13/2008 5:47 PM
To: general-toolchain
Subject: RE: Executable name
________________________________________
From: Ryan Mansfield [community-noreply@qnx.com]
Sent: Wednesday, November 12, 2008 3:57 PM
To: general-toolchain
Subject: Re: Executable name
Mario Charest wrote:
> Using custom makefile that are basicaly identical under Windows and QNX6, the executable name in the ELF file is
different. When build under QNX6 the filename matches the file in ELF, that means if I start the program slay <execname
> will work.
>
> But build under Windows I have to do slay obj/<execname>. I do get around this?
If you build yourself an updated ldrel for 6.3.2 and rebuild
your executable, you should be able to slay it with the proper progname.
Since the problem is for Windows how would I go about compiling a version for Windows? I mean it has to be a windows
binary!!!!
Regards,
Ryan Mansfield
_______________________________________________
General
http://community.qnx.com/sf/go/post16496
_______________________________________________
General
http://community.qnx.com/sf/go/post16544
|
|
|
|
|
|
Mario Charest
11/14/2008 7:46 AM
post16571
|
Nah still can`t use 640 until we can build 6.3.2 executable (gcc 3) from 6.4.0 (self-hosted)
________________________________________
From: Colin Burgess [community-noreply@qnx.com]
Sent: Thursday, November 13, 2008 9:33 PM
To: general-toolchain
Subject: RE: Executable name
Ryan isn't the 640 version fixed? Mario you have the 640 release version, right?
-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com]
Sent: Thu 11/13/2008 5:47 PM
To: general-toolchain
Subject: RE: Executable name
________________________________________
From: Ryan Mansfield [community-noreply@qnx.com]
Sent: Wednesday, November 12, 2008 3:57 PM
To: general-toolchain
Subject: Re: Executable name
Mario Charest wrote:
> Using custom makefile that are basicaly identical under Windows and QNX6, the executable name in the ELF file is
different. When build under QNX6 the filename matches the file in ELF, that means if I start the program slay <execname
> will work.
>
> But build under Windows I have to do slay obj/<execname>. I do get around this?
If you build yourself an updated ldrel for 6.3.2 and rebuild
your executable, you should be able to slay it with the proper progname.
Since the problem is for Windows how would I go about compiling a version for Windows? I mean it has to be a windows
binary!!!!
Regards,
Ryan Mansfield
_______________________________________________
General
http://community.qnx.com/sf/go/post16496
_______________________________________________
General
http://community.qnx.com/sf/go/post16544
_______________________________________________
General
http://community.qnx.com/sf/go/post16548
|
|
|
|
|
|
Ryan Mansfield(deleted)
11/14/2008 8:06 AM
post16573
|
Mario Charest wrote:
> Nah still can`t use 640 until we can build 6.3.2 executable (gcc 3) from 6.4.0 (self-hosted)
I think Colin was suggesting you replace your 6.3.2 ldrel with the 6.4.0
ldrel. You don't need to switch your entire SDK just to pick up this fix.
Regards,
Ryan Mansfield
> ______________________________________
> From: Colin Burgess [community-noreply@qnx.com]
> Sent: Thursday, November 13, 2008 9:33 PM
> To: general-toolchain
> Subject: RE: Executable name
>
> Ryan isn't the 640 version fixed? Mario you have the 640 release version, right?
>
>
> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Thu 11/13/2008 5:47 PM
> To: general-toolchain
> Subject: RE: Executable name
>
>
>
> ________________________________________
> From: Ryan Mansfield [community-noreply@qnx.com]
> Sent: Wednesday, November 12, 2008 3:57 PM
> To: general-toolchain
> Subject: Re: Executable name
>
> Mario Charest wrote:
>> Using custom makefile that are basicaly identical under Windows and QNX6, the executable name in the ELF file is
different. When build under QNX6 the filename matches the file in ELF, that means if I start the program slay <execname
> will work.
>>
>> But build under Windows I have to do slay obj/<execname>. I do get around this?
>
> If you build yourself an updated ldrel for 6.3.2 and rebuild
> your executable, you should be able to slay it with the proper progname.
>
> Since the problem is for Windows how would I go about compiling a version for Windows? I mean it has to be a windows
binary!!!!
>
> Regards,
>
> Ryan Mansfield
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post16496
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post16544
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post16548
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post16571
>
|
|
|
|
|
|
Mario Charest
11/14/2008 11:41 AM
post16587
|
Oh sorry. That indeed fixed the problem.
Thanks !!!!!
________________________________________
From: Ryan Mansfield [community-noreply@qnx.com]
Sent: Friday, November 14, 2008 8:06 AM
To: general-toolchain
Subject: Re: Executable name
Mario Charest wrote:
> Nah still can`t use 640 until we can build 6.3.2 executable (gcc 3) from 6.4.0 (self-hosted)
I think Colin was suggesting you replace your 6.3.2 ldrel with the 6.4.0
ldrel. You don't need to switch your entire SDK just to pick up this fix.
Regards,
Ryan Mansfield
> ______________________________________
> From: Colin Burgess [community-noreply@qnx.com]
> Sent: Thursday, November 13, 2008 9:33 PM
> To: general-toolchain
> Subject: RE: Executable name
>
> Ryan isn't the 640 version fixed? Mario you have the 640 release version, right?
>
>
> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Thu 11/13/2008 5:47 PM
> To: general-toolchain
> Subject: RE: Executable name
>
>
>
> ________________________________________
> From: Ryan Mansfield [community-noreply@qnx.com]
> Sent: Wednesday, November 12, 2008 3:57 PM
> To: general-toolchain
> Subject: Re: Executable name
>
> Mario Charest wrote:
>> Using custom makefile that are basicaly identical under Windows and QNX6, the executable name in the ELF file is
different. When build under QNX6 the filename matches the file in ELF, that means if I start the program slay <execname
> will work.
>>
>> But build under Windows I have to do slay obj/<execname>. I do get around this?
>
> If you build yourself an updated ldrel for 6.3.2 and rebuild
> your executable, you should be able to slay it with the proper progname.
>
> Since the problem is for Windows how would I go about compiling a version for Windows? I mean it has to be a windows
binary!!!!
>
> Regards,
>
> Ryan Mansfield
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post16496
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post16544
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post16548
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post16571
>
_______________________________________________
General
http://community.qnx.com/sf/go/post16573
|
|
|
|
|
|
Ryan Mansfield(deleted)
11/14/2008 8:04 AM
post16572
|
Colin Burgess wrote:
> Ryan isn't the 640 version fixed? Mario you have the 640 release
> version, right?
Yeah, it's fixed in 6.4.
Regards,
Ryan Mansfield
|
|
|
|
|
|
