Emit OPD reloc for all global symbols and then some.

Quoted 7 lines

Under hppa-linux:
------------------
We want to generate a PLABEL32 (OPD reloc) against all global symbols, and then some. For example it should be possible for an application to call dlsym asking for the address of main, and when compared to main it should match.

Does it work on Linux/ia32? If not, why should it work on Linux/hppa?

Quoted 9 lines

Quoted 7 lines

Under hppa-linux:
------------------
We want to generate a PLABEL32 (OPD reloc) against all global symbols, and then some. For example it should be possible for an application to call dlsym asking for the address of main, and when compared to main it should match.

Does it work on Linux/ia32? If not, why should it work on Linux/hppa?

The linux manpage for dlsym indicates that symbols in the main program can be looked up with dlsym:

If filename is a NULL pointer, then the returned handle is for the main program. When given to dlsym(), this handle causes a search for a symbol in the main program, followed by all shared libraries loaded at program startup, and then all shared libraries loaded by dlopen() with the flag RTLD_GLOBAL.

So, if it doesn't work, that would seem to be a bug in Linux/ia32.

Quoted 20 lines · John David Anglin

Quoted 9 lines

Quoted 7 lines

Under hppa-linux:
------------------
We want to generate a PLABEL32 (OPD reloc) against all global symbols, and then some. For example it should be possible for an application to call dlsym asking for the address of main, and when compared to main it should match.

Does it work on Linux/ia32? If not, why should it work on Linux/hppa?

The linux manpage for dlsym indicates that symbols in the main program can be looked up with dlsym:

If filename is a NULL pointer, then the returned handle is for the main program. When given to dlsym(), this handle causes a search for a symbol in the main program, followed by all shared libraries loaded at program startup, and then all shared libraries loaded by dlopen() with the flag RTLD_GLOBAL.

Quoted 1 line

So, if it doesn't work, that would seem to be a bug in Linux/ia32.

It works if the global symbol is exported. But not all global symbols in main are exported by default. You can use --export-dynamic to export all global symbols.

Quoted 21 lines · H. J. Lu

Quoted 20 lines · John David Anglin

Quoted 9 lines

Quoted 7 lines

Under hppa-linux:
------------------
We want to generate a PLABEL32 (OPD reloc) against all global symbols, and then some. For example it should be possible for an application to call dlsym asking for the address of main, and when compared to main it should match.

Does it work on Linux/ia32? If not, why should it work on Linux/hppa?

The linux manpage for dlsym indicates that symbols in the main program can be looked up with dlsym:

If filename is a NULL pointer, then the returned handle is for the main program. When given to dlsym(), this handle causes a search for a symbol in the main program, followed by all shared libraries loaded at program startup, and then all shared libraries loaded by dlopen() with the flag RTLD_GLOBAL.

Quoted 5 lines

Quoted 1 line

So, if it doesn't work, that would seem to be a bug in Linux/ia32.

It works if the global symbol is exported. But not all global symbols in main are exported by default. You can use --export-dynamic to export all global symbols.

Regardless of wether or not I export all global symbols in main, I must still emit OPD relocs in the executable for all dynamic symbols. In the

past the OPD reloc was "fudged" and pointed at the PLT, and this is not a satisfactory situation. I want ld.so.1 to generate the OPD so we no longer need gcc to emit the __cffc helper function for comparisons.

Quoted 2 lines

Regardless of wether or not I export all global symbols in main, I must still emit OPD relocs in the executable for all dynamic symbols. In the

						^^^^^^^^^^

Did you mean dynamic or global? There is a big difference. In your proposal, you said "We want to generate a PLABEL32 (OPD reloc) against all global symbols,". I am not familiar with HPPA. I just want to know what you have in mind.

Quoted 3 lines

past the OPD reloc was "fudged" and pointed at the PLT, and this is not a satisfactory situation. I want ld.so.1 to generate the OPD so we no longer need gcc to emit the __cffc helper function for comparisons.

Quoted 8 lines

Quoted 2 lines

Regardless of wether or not I export all global symbols in main, I must still emit OPD relocs in the executable for all dynamic symbols. In the

						^^^^^^^^^^

Did you mean dynamic or global? There is a big difference. In your proposal, you said "We want to generate a PLABEL32 (OPD reloc) against all global symbols,". I am not familiar with HPPA. I just want to know what you have in mind.

Sorry for being sloppy, there is a qualifier in my mind that I keep forgetting to write, read the following:

ld must emit an OPD reloc in the executable for each global symbol that had an OPD reloc to begin with. This way the dynamic loader can assign an OPD at runtime for use in a comparison. Dynamic symbols that had an OPD reloc should also emit the reloc in the executable.

Quoted 1 line

From my standpoint, I would like to see the same behavior for both

Having the PLABEL32 relocation resolve to an OPD appears to require that the symbol be exported. As a result, we have a different behaviors for dlsym on hppa and ia32. What's ia64 do?

Quoted 1 line

From my standpoint, I would like to see the same behavior for both

32 and 64-bit links when hppa linux supports both 32 and 64-bit user spaces.

The original linux implementation was modelled on hpux
but over the years we have found that hpux compatibility isn't important.

Quoted 3 lines · John David Anglin

Having the PLABEL32 relocation resolve to an OPD appears to require that the symbol be exported. As a result, we have a different behaviors for dlsym on hppa and ia32. What's ia64 do?

hppa needs to be fixed to implement correct variants of the macros in dl-lookupcfg.h. It probably just has to copy the definitions of DL_FIXUP_* from sysdeps/ia64/dl-lookupcfg.h, and _dl_runtime_{resolve,profile} has to be adapted accordingly.

Quoted 6 lines

Quoted 3 lines · John David Anglin

Having the PLABEL32 relocation resolve to an OPD appears to require that the symbol be exported. As a result, we have a different behaviors for dlsym on hppa and ia32. What's ia64 do?

Quoted 4 lines

hppa needs to be fixed to implement correct variants of the macros in dl-lookupcfg.h. It probably just has to copy the definitions of DL_FIXUP_* from sysdeps/ia64/dl-lookupcfg.h, and _dl_runtime_{resolve,profile} has to be adapted accordingly.

There could be problems here but it seems that hppa is exporting all global symbols in .dynsym.

Regarding the patch, I'm not sure why but it seems to result in more R_PARISC_NONE dynamic relocation records (one for each real dynamic relocation?).

Quoted 10 lines

Quoted 3 lines · John David Anglin

Having the PLABEL32 relocation resolve to an OPD appears to require that the symbol be exported. As a result, we have a different behaviors for dlsym on hppa and ia32. What's ia64 do?

hppa needs to be fixed to implement correct variants of the macros in dl-lookupcfg.h. It probably just has to copy the definitions of DL_FIXUP_* from sysdeps/ia64/dl-lookupcfg.h, and _dl_runtime_{resolve,profile} has to be adapted accordingly.

There could be problems here but it seems that hppa is exporting all global symbols in .dynsym.

Regarding the patch, I'm not sure why but it seems to result in more R_PARISC_NONE dynamic relocation records (one for each real dynamic relocation?).

Quoted 11 lines · John David Anglin

Quoted 10 lines

Quoted 3 lines · John David Anglin

Having the PLABEL32 relocation resolve to an OPD appears to require that the symbol be exported. As a result, we have a different behaviors for dlsym on hppa and ia32. What's ia64 do?

hppa needs to be fixed to implement correct variants of the macros in dl-lookupcfg.h. It probably just has to copy the definitions of DL_FIXUP_* from sysdeps/ia64/dl-lookupcfg.h, and _dl_runtime_{resolve,profile} has to be adapted accordingly.

Quoted 2 lines

There could be problems here but it seems that hppa is exporting all global symbols in .dynsym.

Why does hppa do that? A global symbol in executable should be exported only if it is referenced by a DSO or --export-dynamic is used.

Quoted 5 lines

Regarding the patch, I'm not sure why but it seems to result in more R_PARISC_NONE dynamic relocation records (one for each real dynamic relocation?).

IA64 also uses function descriptors. Everything works fine.

Quoted 3 lines · John David Anglin

Having the PLABEL32 relocation resolve to an OPD appears to require that the symbol be exported. As a result, we have a different behaviors for dlsym on hppa and ia32. What's ia64 do?

hppa needs to be fixed to implement correct variants of the macros in dl-lookupcfg.h. It probably just has to copy the definitions of DL_FIXUP_* from sysdeps/ia64/dl-lookupcfg.h, and _dl_runtime_{resolve,profile} has to be adapted accordingly.

Quoted 3 lines · John David Anglin

Quoted 1 line

From my standpoint, I would like to see the same behavior for both

32 and 64-bit links when hppa linux supports both 32 and 64-bit user spaces.

Yeah, that would make sense.

Quoted 3 lines

The original linux implementation was modelled on hpux
but over the years we have found that hpux compatibility isn't important.

When I first got involved in parisc-linux in 1999, there was an interest in commercializing parisc-linux. That would mean investing several million dollars per year on a team to support/test parisc-linux *and* compatibility (where possible) with hpux so customers could run smaller apps on both. HP chose not to do that (it was a very rational decision though personally disappointing). parisc-linux did not get commercialized and the developer community around parisc-linux is not interested in HPUX compatibility.

If someone is interested in HPUX application compatibility, they better start providing parisc-linux kernel patches this year. An ABI compatibility event in the tool chain would be sufficient reason for me to rip out the broken HPUX compatibility support currently in the parisc-linux source tree.
So far, I've lobbied to keep HPUX app support in the tree with the hope we could someday run the HPUX X11 server (3D HW Accel!). But the right people haven't volunteered to make that work.

Quoted 8 lines · H. J. Lu

Quoted 2 lines

Regardless of wether or not I export all global symbols in main, I must still emit OPD relocs in the executable for all dynamic symbols. In the

						^^^^^^^^^^

Did you mean dynamic or global? There is a big difference. In your proposal, you said "We want to generate a PLABEL32 (OPD reloc) against all global symbols,". I am not familiar with HPPA. I just want to know what you have in mind.

Sorry for being sloppy, there is a qualifier in my mind that I keep forgetting to write, read the following:

ld must emit an OPD reloc in the executable for each global symbol that had an OPD reloc to begin with. This way the dynamic loader can assign an OPD at runtime for use in a comparison. Dynamic symbols that had an OPD reloc should also emit the reloc in the executable.

Previously an executable just pointed the OPD data word for global and dynamic symbols at their associated .plt entries (since .plt entries like on ia64 are function descriptors). No OPD reloc emitted. Thus the address of the OPD was really the address of the .plt entry.

This meant that if you passed the address of a dynamic symbol to a shared library function, from which the symbol came from, the two addresses would be different. One would point to the executables .plt entry for that dynamic symbol, while the shared library would have an OPD for that symbol. The ip/gp of both would be the same though (after resolution of the .plt that is).

The shared case in hppa was always different, and a DSO has always created OPD relocs against symbols that started with OPD relocs.

Quoted 3 lines

Quoted 3 lines

past the OPD reloc was "fudged" and pointed at the PLT, and this is not a satisfactory situation. I want ld.so.1 to generate the OPD so we no longer need gcc to emit the __cffc helper function for comparisons.

Calling through the .plt is still faster than calling through an OPD. You can still call through an OPD using $dyncall in hppa. Thus we probably want to keep the .plt entry even though we are creating an OPD that could be used to call through.