llvm: stubbed st_size does matter for copy-relocs/bss

llvm: stubbed st_size does matter for copy-relocs/bss

Handle a few more cases that were not handled before and
issue a (DEBUG) warning if there is any unknown case.

This may help fix references to stderr, optarg, etc.,
when we turn off PIC for the dynamic executable and turn on
metadata for the final link.  Without the size, gold will
avoid putting things in BSS w/ copy relocs, and attempt
to add a TEXTREL, which I think isn't supported by NaCl.

BUG= http://code.google.com/p/nativeclient/issues/detail?id=2370
TEST= run_gettimeofday_test

[robertm, 2012-04-25 17:42:07]

http://codereview.chromium.org/10151020/diff/1/llvm/tools/llc/StubMaker.cpp
File llvm/tools/llc/StubMaker.cpp (right):

http://codereview.chromium.org/10151020/diff/1/llvm/tools/llc/StubMaker.cpp#n...
llvm/tools/llc/StubMaker.cpp:132: DEBUG({
would it be better to assert for now?
otherwise we might get hard to catch errors.

http://codereview.chromium.org/10151020/diff/1/llvm/tools/llc/StubMaker.cpp#n...
llvm/tools/llc/StubMaker.cpp:143: // in a data object.  This is important for
symbols that may sit in BSS
why wouldn't it also be important for non bss symbols?
Maybe add some more info while it is still fresh  in your mind.

[jvoung - send to chromium..., 2012-04-25 18:20:51]

http://codereview.chromium.org/10151020/diff/1/llvm/tools/llc/StubMaker.cpp
File llvm/tools/llc/StubMaker.cpp (right):

http://codereview.chromium.org/10151020/diff/1/llvm/tools/llc/StubMaker.cpp#n...
llvm/tools/llc/StubMaker.cpp:132: DEBUG({
On 2012/04/25 17:42:07, robertm wrote:
> would it be better to assert for now?
> otherwise we might get hard to catch errors.

Good point. Switched over to an assert and already caught a bug =)

(ArrayType ElemSize computation should have been a recursive call).

Actually, now I'm worried that the ELF -> PSO-stub maker is too loose about
datatype and size (might lose info there), but that's a different issue... 
hopefully only pointers are exported I guess.

http://codereview.chromium.org/10151020/diff/1/llvm/tools/llc/StubMaker.cpp#n...
llvm/tools/llc/StubMaker.cpp:143: // in a data object.  This is important for
symbols that may sit in BSS
On 2012/04/25 17:42:07, robertm wrote:
> why wouldn't it also be important for non bss symbols?
> Maybe add some more info while it is still fresh  in your mind.

Well, I'm not sure, but I don't think it matters for functions.  Rephrased.

[jvoung - send to chromium..., 2012-04-25 18:22:19]

http://codereview.chromium.org/10151020/diff/1/llvm/tools/llc/StubMaker.cpp
File llvm/tools/llc/StubMaker.cpp (right):

http://codereview.chromium.org/10151020/diff/1/llvm/tools/llc/StubMaker.cpp#n...
llvm/tools/llc/StubMaker.cpp:132: DEBUG({
On 2012/04/25 18:20:51, jvoung wrote:
> On 2012/04/25 17:42:07, robertm wrote:
> > would it be better to assert for now?
> > otherwise we might get hard to catch errors.
> 
> Good point. Switched over to an assert and already caught a bug =)
> 
> (ArrayType ElemSize computation should have been a recursive call).
> 
> Actually, now I'm worried that the ELF -> PSO-stub maker is too loose about
> datatype and size (might lose info there), but that's a different issue... 
> hopefully only pointers are exported I guess.

Err... n/m about the PSO stub. The header file should let the pexe know the type
of things and get the declaration.

[robertm, 2012-04-25 18:40:20]

LGTM