Tags: application, code, coded, contains, existing, generation, older, operating, porting, software, solaris, source, sparc, sun, system, unixoperating
Porting hard coded code to Solaris
On Software » Solaris Operating System
13,786 words with 9 Comments; publish: Tue, 20 May 2008 01:00:00 GMT; (40078.13, « »)
I am porting an application with C code from an older generation Unix
Operating System to SUN Solaris on Sun SPARC.
The existing source code contains some platform specific hard-coded
address declarations for shared memory creation & use.
I am trying to figure out what would be the runtime impact of such
declarations on Solaris system.
Following are the details :
The address is declared as follows
#define SHM_ABAOFF_ADDR ((void *) 0x8001000)
The address declared is used to attach to Shared Memory as follows
S = (ABAOFF_STRUCT *) shmat(abaoff_id, SHM_ABAOFF_ADDR, 0);
The above is used in several executable and so all the
executables attach themselves to the same shared memory segment.
I am trying to understand
1. Will such coding work on Solaris Platform as it is?
2. Will I need to make any changes to the address to make it work?
3. What changes in logic/architecture will be required.
Thanks
Nits
http://solaris.itags.org/q_solaris_31967.html
All Comments
Leave a comment...
- 9 Comments
- Nits wrote:
> I am porting an application with C code from an older generation Unix
> Operating System to SUN Solaris on Sun SPARC.
> The existing source code contains some platform specific hard-coded
> address declarations for shared memory creation & use.
> I am trying to figure out what would be the runtime impact of such
> declarations on Solaris system.
> Following are the details :
> The address is declared as follows
> #define SHM_ABAOFF_ADDR ((void *) 0x8001000)
> The address declared is used to attach to Shared Memory as follows
> S = (ABAOFF_STRUCT *) shmat(abaoff_id, SHM_ABAOFF_ADDR, 0);
> The above is used in several executable and so all the
> executables attach themselves to the same shared memory segment.
> I am trying to understand
> 1. Will such coding work on Solaris Platform as it is?
> 2. Will I need to make any changes to the address to make it work?
> 3. What changes in logic/architecture will be required.
> Thanks
> Nits
>
did you read shmat? Are there any remaining questions?
#1; Tue, 20 May 2008 01:02:00 GMT
- "Thomas Maier-Komor" <maierkom.solaris.itags.org.lpr.e-technik.no-spam.tu-muenchen.de> wrote
in message news:ct5kos$10l$1.solaris.itags.org.wsc10.lrz-muenchen.de...
> Nits wrote:
> did you read shmat? Are there any remaining questions?
This is something that has always perplexed me. According to the man page,
if you pass in an address to shmat, it will attach the segment to that
address.
But what it doesn't say is what a valid range for addresses is. The memory
map of a modern C application is a bit of a mystery (to me at least), so how
do you know how to select an address that you want to share across
applications, that you know will work. In the OP's post, the address he used
(#define SHM_ABAOFF_ADDR ((void *) 0x8001000)) seems fairly arbitrary.
So, where can one find a mapping of legal addresses that you can safely use
for this purpose? I suppose the same question is valid for mmap as well.
Regards,
Will Hartung
(willh.solaris.itags.org.msoft.com)
#2; Tue, 20 May 2008 01:03:00 GMT
- On Tue, 25 Jan 2005, Will Hartung wrote:
> This is something that has always perplexed me. According to the man page,
> if you pass in an address to shmat, it will attach the segment to that
> address.
> But what it doesn't say is what a valid range for addresses is. The memory
That's because that is very system dependant.
> map of a modern C application is a bit of a mystery (to me at least), so h
ow
> do you know how to select an address that you want to share across
> applications, that you know will work. In the OP's post, the address he us
ed
> (#define SHM_ABAOFF_ADDR ((void *) 0x8001000)) seems fairly arbitrary.
By specifying an address of 0, you tell the OS to decide what the
best address is. Portable apps should therefore use an address of 0.
> So, where can one find a mapping of legal addresses that you can safely us
e
> for this purpose? I suppose the same question is valid for mmap as well.
More often than not, 0 is the best address to use.
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
#3; Tue, 20 May 2008 01:04:00 GMT
- "Will Hartung" <willh.solaris.itags.org.msoft.com> writes:
> applications, that you know will work. In the OP's post, the address he us
ed
> (#define SHM_ABAOFF_ADDR ((void *) 0x8001000)) seems fairly arbitrary.
> So, where can one find a mapping of legal addresses that you can safely us
e
> for this purpose? I suppose the same question is valid for mmap as well.
Well, you just try to attach to the address and if it fails, you have to
find another one. We used to build a 'hunter program' that would find such
a hole and unless you change something dramatically, you stick to that one
(it could be different on different platforms). However, it is better to
change the code not to depend on the fixed address and to use relative
pointers.
And no, it is not the same for mmap: mmap(2) automatically performs
munmap(2) of the region that was previously mapped and that you try to mmap
now and it can break things. It happened to me once or twice that I have
managed to munmap the part of the memory mapped by libc, which my program
didn't like :-)
Dragan
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!!
#4; Tue, 20 May 2008 01:05:00 GMT
- Will Hartung wrote:
> "Thomas Maier-Komor" <maierkom.solaris.itags.org.lpr.e-technik.no-spam.tu-muenchen.de> wrote
> in message news:ct5kos$10l$1.solaris.itags.org.wsc10.lrz-muenchen.de...
>
>
> This is something that has always perplexed me. According to the man page,
> if you pass in an address to shmat, it will attach the segment to that
> address.
> But what it doesn't say is what a valid range for addresses is. The memory
> map of a modern C application is a bit of a mystery (to me at least), so h
ow
> do you know how to select an address that you want to share across
> applications, that you know will work. In the OP's post, the address he us
ed
> (#define SHM_ABAOFF_ADDR ((void *) 0x8001000)) seems fairly arbitrary.
> So, where can one find a mapping of legal addresses that you can safely us
e
> for this purpose? I suppose the same question is valid for mmap as well.
> Regards,
> Will Hartung
> (willh.solaris.itags.org.msoft.com)
>
What sense would it make to map to a specific address. This is not for
mapping hardware I/O ranges... That what reason should there be other
than map an existing shared memory segment in a different process to the
same address. But then you already have to know about the shared memory
segment, and if you got to know the shared memory id then you can also
pass the information where it was placed, when it was mapped the first
time.
What do I miss?
Cheers,
Tom
#5; Tue, 20 May 2008 01:06:00 GMT
- dragan_usenet.solaris.itags.org.gmx.net writes in comp.unix.solaris:
|"Will Hartung" <willh.solaris.itags.org.msoft.com> writes:
|
|> applications, that you know will work. In the OP's post, the address he u
sed
|> (#define SHM_ABAOFF_ADDR ((void *) 0x8001000)) seems fairly arbitrary.
|>
|> So, where can one find a mapping of legal addresses that you can safely u
se
|> for this purpose? I suppose the same question is valid for mmap as well.
|
|Well, you just try to attach to the address and if it fails, you have to
|find another one.
For shmat that may work, but for mmap, that's still dangerous, as I saw
someone here find out the hard way when porting code that used that
technique. mmap() won't fail if the address given is an already in use
mapping, but instead assumes you know what you're doing and replaces the
old mapping - not good when that just happens to be the address one of
your shared libraries was mapped to.
________________________________________
________________________________
Alan Coopersmith * alanc.solaris.itags.org.alum.calberkeley.org * Alan.Coopersmith.solaris.itags.org.Sun.COM
http://www.csua.berkeley.edu/~alanc/ * http://blogs.sun.com/alanc/
Working for, but definitely not speaking for, Sun Microsystems, Inc.
#6; Tue, 20 May 2008 01:07:00 GMT
- Thomas Maier-Komor <maierkom.solaris.itags.org.lpr.e-technik.no-spam.tu-muenchen.de> writes:
> Will Hartung wrote:
> What sense would it make to map to a specific address. This is not for
> mapping hardware I/O ranges... That what reason should there be other
> than map an existing shared memory segment in a different process to the
> same address. But then you already have to know about the shared memory
> segment, and if you got to know the shared memory id then you can also
> pass the information where it was placed, when it was mapped the first
> time.
> What do I miss?
It could be useful if you're re-hosting low-level sofware written with
more or less hardcoded addresses used on its original platform.
Perhaps the application is to simulate a shared bus located in that
address range with separate Solaris processes simulating the separate
processors- the code being ported to Solaris because they want a
convenient test platform and don't want to perturb the application by
changing around the "hardware" addresses.
Gregm
#7; Tue, 20 May 2008 01:08:00 GMT
- Greg Menke wrote:
> Thomas Maier-Komor <maierkom.solaris.itags.org.lpr.e-technik.no-spam.tu-muenchen.de> writes:
>
>
> It could be useful if you're re-hosting low-level sofware written with
> more or less hardcoded addresses used on its original platform.
> Perhaps the application is to simulate a shared bus located in that
> address range with separate Solaris processes simulating the separate
> processors- the code being ported to Solaris because they want a
> convenient test platform and don't want to perturb the application by
> changing around the "hardware" addresses.
> Gregm
indeed - that seems to be a reason. weird stuff exists...
Tom
#8; Tue, 20 May 2008 01:09:00 GMT
- In article <ct6bn6$19hr$1.solaris.itags.org.agate.berkeley.edu>,
Alan Coopersmith <alanc.solaris.itags.org.alum.calberkeley.org> writes:
> dragan_usenet.solaris.itags.org.gmx.net writes in comp.unix.solaris:
>|"Will Hartung" <willh.solaris.itags.org.msoft.com> writes:
>|
>|> applications, that you know will work. In the OP's post, the address he
used
>|> (#define SHM_ABAOFF_ADDR ((void *) 0x8001000)) seems fairly arbitrary.
>|>
>|> So, where can one find a mapping of legal addresses that you can safely
use
>|> for this purpose? I suppose the same question is valid for mmap as well.
>|
>|Well, you just try to attach to the address and if it fails, you have to
>|find another one.
> For shmat that may work, but for mmap, that's still dangerous, as I saw
> someone here find out the hard way when porting code that used that
> technique. mmap() won't fail if the address given is an already in use
> mapping, but instead assumes you know what you're doing and replaces the
> old mapping - not good when that just happens to be the address one of
> your shared libraries was mapped to.
That's true of shmat() on some systems too (not Solaris though).
When faced with a large complex set of programs which all needed to
share some memory at the same address (and no chance to change them
to use relative addresses as they should have from the start), here's
what I did. This worked on Solaris and a number of other unixes, but
was not completely universal.
Find an unused hole in your address space which is around 4Mb bigger
than the shared memory area you need. Do this by allocating such an
area with mmap() MAP_NORESERVE, noting the address, and then unmapping
it. Add 4Mb to the address mmap() gave you, and use this as the
address to shmat, and write the address into the shared memory at a
known offset. Subsequent programs then shmat() initially allowing the
OS to choose the address, read the required address from the shared
memory, detach and reattach at the right address. This trick often
works because the first mmap finds the area above all the linked
libraries, and the 4Mb extra allows for other processes to have some
extra libraries linked in and still have the same area free. However,
it's not completely guaranteed to work, and you should also have a
config file which allows the 4Mb value to be changed, and/or allows
an explicit address to be specified to override this auto-configure
mechanism so a customer can work around any issue in the field without
you having to deliver a new binary.
Andrew Gabriel
#9; Tue, 20 May 2008 01:10:00 GMT