intent of objcopy in src/Makefile.inc

[Steve Byan's Lists]

Would someone please explain the purpose of the objcopy recipe in Makefile.inc? I'm trying to modify the makefiles to support a couple of non-GNU toolchains, and I want to make sure I understand the intent.

The sed script appears to be broken. It appears that it was intended to output "-G pmem_map" etc but because of the double dollar-sign, it outputs nothing. Presumably the intent was to make only the symbols listed in the global section of libpmem.map externally visible.

I'm also unclear on the meaning of the --localize-hidden option. I'm pretty ignorant of ELF, so the man page description doesn't help much. What is the meaning and purpose of marking "all symbols that have hidden or internal visibility as local"?

Best regards,
-Steve

--
Steve Byan
stev...@me.com
Littleton, MA

[Krzysztof Czurylo]

Hi Steve,

I believe the sed script does what it is intended to do... Note that it is executed from makefile, so because of the special meaning of "$" in makefiles, to have one dollar sign you actually need to double it.

And yes, the intent was to hide all the symbols that are not listed int the global section of the *.map files.

Regarding "--localize-hidden". I assume it has more or less the same meaning as "-fvisibility=hidden" (http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Code-Gen-Options.html).

Seems like now it's not necessary at all, as we explicitly declare all the local functions as "static".

In fact, I did a quick test and I don't see any difference int the output binaries regardless of whether this flag is specified or not. It could be different in the past.

We'll revisit this. Perhaps using "-fvisibility=hidden" would be better - it produces a bit smaller binaries.

Thanks,

K.

[Andy Rudoff]

To add to what Krzysztof wrote: the history of the sed line is that the map file only applies to shared libraries, so I wanted to make sure that non-static symbols in the library (i.e. because of a call from one .c file in the library to another .c file in the library) were scoped out.  Since the map file didn't apply to the .a we build, I found I could pass the list of symbols to the linker using the -G option (combined with an option to hide other symbols by default).

That said, the requirement for static linking may not apply to the platform you're porting to, and the way of scoping symbols out is of course tool chain dependent.  But as the libraries are implemented today, we expect all our unit tests to pass on both the shared-library and static versions.

-andy

[Steve Byan's Lists]

Hi Krzysztof,

> On Mar 29, 2016, at 12:03 PM, Krzysztof Czurylo <krzyszto...@intel.com> wrote:
>
> I believe the sed script does what it is intended to do... Note that it is executed from makefile, so because of the special meaning of "$" in makefiles, to have one dollar sign you actually need to double it.

Aargh, yes, thanks for pointing out the quoting. That explains why cutting and pasting to a shell script gave different results.

> And yes, the intent was to hide all the symbols that are not listed int the global section of the *.map files.

Thanks for confirming.

> Regarding "--localize-hidden". I assume it has more or less the same meaning as "-fvisibility=hidden" (http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Code-Gen-Options.html).

Thanks for that pointer. I now know how to get educated on the subject.

[Steve Byan's Lists]

Hi Andy,

> On Mar 29, 2016, at 12:22 PM, Andy Rudoff <an...@rudoff.com> wrote:
>
> To add to what Krzysztof wrote: the history of the sed line is that the map file only applies to shared libraries, so I wanted to make sure that non-static symbols in the library (i.e. because of a call from one .c file in the library to another .c file in the library) were scoped out. Since the map file didn't apply to the .a we build, I found I could pass the list of symbols to the linker using the -G option (combined with an option to hide other symbols by default).

Thanks for clarifying. Once I started working on the dynamic library part of the makefile, I saw the other use of the .map file.

> That said, the requirement for static linking may not apply to the platform you're porting to, and the way of scoping symbols out is of course tool chain dependent. But as the libraries are implemented today, we expect all our unit tests to pass on both the shared-library and static versions.

Are you folks considering autoconfiscating and libtooling the nvml? That would greatly ease porting to non-GNU toolchains and non-GNU make, for example the BSD's.