This option mark all global symbols as weaken.
This option follows the GNU objcopy --weaken option, as it doesn't mark the symbol as weak if this one is undefined (a relocation).
This check tells me whether the symbol is defined or not. If not, it means that it's a relocation.
Well at the very least this isn't the right way to handle the situation you describe. I wasn't aware of this as it doesn't seem to be documented behavior (*highly* common with GNU objcopy). I'm going to ask around on what the behavior *should* be for the intended use cases to see what should happen. It sounds like we may want other 'weaken' options to do the same thing.
I've asked Roland McGrath whats supposed to be happening here but I don't suspect he'll get back to me until Monday. Sorry about that! I'll also do some black box testing of GNU objcopy to see what its doing but it isn't the case that we always want to copy it.
Well, you're definitely right ! I was looking for the section index, and I switched from getShndx() to NameIndex and I still can't explain why I did this..
Alright, the behavior is the same for the --weaken-symbol option. Anyway, my thoughts are that we might not need to change the behavior of this option.
Indeed, as the user explicitly want to weaken a symbol, I think we might weaken it in anyway; or at least, we might throw some sort of warnings (GNU objcopy silently does nothing..)
For this --weaken option, I would also go for this behavior (i.e. weaken every global symbols), as it is the behavior explained in the objcopy man page. Anyway, maybe we are missing something, and Roland McGrath will tell us why they made this choice of keeping undefined symbols global.
What do you think about it ?
FWIW, checking getShndx() == SHN_UNDEF is the correct way to test for undefined symbols currently. This deals with absolute symbols etc happily.
On a related note, what is GNU objcopy's behaviour for --weaken etc and global absolute and common symbols?
So I asked the gods about this and got a half response on this issue but this appears to be intended for localize and globalize and *might* have been intended for weaken. After some thought I don't think it makes a lot of sense to weaken an undefined symbol and it might be unexpected behavior so I'm cool with it working this way. That would be my preference and it gives compatibility with objcopy.
Reading the code snippet Roland pointed out to me I don't think absolute symbols are treated specially but I don't know how common symbols are treated. Paul, can you do some blackbox testing of GNU objcopy to see how common symbols are treated?
Ah! Good catch. I forgot about that.
Sure, here is what I've got so far :
Generally speaking, while copying, objcopy turns common symbols into object symbols. Otherway, it goes the same as it is with other symbol types.
For --globalize-symbol option :
- doesn't do anything for weak symbols
- works with undefined local symbols
For --localize-symbol option:
- works with all (but undef of course) symbols
So, do you think that I need to change the behavior of those two options to match the objcopy behavior ?
Thanks for taking the time to ask Roland McGrath !
I'm happy with this change. I think we should change --globalize and --localize to match but if --globalize-symbol or --localize-symbol is used it shouldn't bother checking; if people want to do non-sense that's their choice. I didn't think about it but it makes a lot of sense not to globalize weak symbols and it makes sense to not localize undefined symbols. So I think the choices objcopy chose makes sense. If you could change those to match that, it would be awesome!