Different set of symbol generated when going through a .s

[Quuxplusone]

Bugzilla Link	PR25811
Status	NEW
Importance	P normal
Reported by	Rafael Ávila de Espíndola (rafael@espindo.la)
Reported on	2015-12-11 13:06:06 -0800
Last modified on	2015-12-14 10:51:41 -0800
Version	unspecified
Hardware	PC Linux
CC	dblaikie@gmail.com, emaste@freebsd.org, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments	test.ll (1493 bytes, application/octet-stream)
Blocks
Blocked by
See also

Created attachment 15432
test

Compiling the attached file with

$ llc -mtriple=armv7l-linux-eabihf -filetype=asm -o t.s test.ll
$ llvm-mc -triple=armv7l-linux-eabihf -o t.o -filetype=obj t.s

and with

$ llc -march=armv7l-linux-eabihf -filetype=obj -o t.o test.ll

Produces files with a different set of symbols.

I call attention to the set of symbols and not to other differences to note
that this is probably not a simple duplicate of pr18716

[Quuxplusone]

Attached test.ll (1493 bytes, application/octet-stream): test

[Quuxplusone]

Is there anything obviously noteworthy about the symbols that are different? (are there equivalent symbols with slightly different names? Outright missing/extraneous symbols, etc?)

Perhaps you could attach a diff of the symbols in a comment on the bug.

[Quuxplusone]

(In reply to comment #1)
> Is there anything obviously noteworthy about the symbols that are different?
> (are there equivalent symbols with slightly different names? Outright
> missing/extraneous symbols, etc?)

Yes, it is the .Linfo_string* symbols that are missing.

The best fix would be to fix pr23933, that way llvm-mc is sure to avoid the
names too.

For now we should check if gas keeps the symbols if passed the llc output. If
so we need to find out why and implement that why in the code that is deciding
to not create names for them.

If gas avoids keeping the symbols, we should make sure llvm-mc can do that too.