[assembler] Introduce proper AssemblerBase::Print() for improved debuggability.

[assembler] Introduce proper AssemblerBase::Print() for improved debuggability.

While working on frame elision, I wanted to disassemble codegen in the
debugger, as the code generation is progressing. I discovered we had a
 "Print" member on the x64 assembler, without any implementation. I
pulled it up to AssemblerBase and gave it an implementation that
should work for the other architectures.

Also checked that ia32, x87, arm and arm64 assemblers didn't have
such an implementation - free Print.

Arm64 has a naming conflict with the v8::internal::Disassembler. I
renamed the arm64 type with a more specific name.

Opportunistically fixed a bug in the name converter. This debug-time
printer doesn't provide a Code object, which should be OK with the
name converters, by the looks of other APIs there. All this means is that
when using the Print() API, we just get addresses dumped without any
context (like what this address may be - a stub maybe, etc). This seems
fine for the scenario.

There may be other places that assume a Code object. Since this is
a diagnostics-only scenario, for codegen developers, I feel it is
reasonable to fix such other places as we find them.

Committed: https://crrev.com/ab1d270a72a2c0553eb0b7d47eb6fa16ecc038c6
Cr-Commit-Position: refs/heads/master@{#31869}

[Mircea Trofin, 2015-11-07 16:55:55]

Description was changed from

==========
Macro assembler debuggability

BUG=
==========

to

==========
Macro assembler debuggability.

While working on frame elision, I wanted to disassemble codegen in the 
debugger, as the code generation is progressing. I discovered we had a
 "Print" member on the x64 assembler, without any implementation. I 
pulled it up to AssemblerBase and gave it an implementation that 
should work for the other architectures.

Also checked that ia32, x87, arm and arm64 assemblers didn't have 
such an implementation - free Print.

Opportunistically fixed a bug in the name converter. This debug-time
printer doesn't provide a Code object, which should be OK with the 
name converters, by the looks of other APIs there. All this means is that
when using the Print() API, we just get addresses dumped without any
context (like what this address may be - a stub maybe, etc). This seems
fine for the scenario.

There may be other places that assume a Code object. Since this is
a diagnostics-only scenario, for codegen developers, I feel it is 
reasonable to fix such other places as we find them.
 
BUG=
==========

[Mircea Trofin, 2015-11-07 16:55:55]

mtrofin@chromium.org changed reviewers:
+ bmeurer@chromium.org, jarin@chromium.org

[Mircea Trofin, 2015-11-08 18:41:11]

Description was changed from

==========
Macro assembler debuggability.

While working on frame elision, I wanted to disassemble codegen in the 
debugger, as the code generation is progressing. I discovered we had a
 "Print" member on the x64 assembler, without any implementation. I 
pulled it up to AssemblerBase and gave it an implementation that 
should work for the other architectures.

Also checked that ia32, x87, arm and arm64 assemblers didn't have 
such an implementation - free Print.

Opportunistically fixed a bug in the name converter. This debug-time
printer doesn't provide a Code object, which should be OK with the 
name converters, by the looks of other APIs there. All this means is that
when using the Print() API, we just get addresses dumped without any
context (like what this address may be - a stub maybe, etc). This seems
fine for the scenario.

There may be other places that assume a Code object. Since this is
a diagnostics-only scenario, for codegen developers, I feel it is 
reasonable to fix such other places as we find them.
 
BUG=
==========

to

==========
Macro assembler debuggability.

While working on frame elision, I wanted to disassemble codegen in the 
debugger, as the code generation is progressing. I discovered we had a
 "Print" member on the x64 assembler, without any implementation. I 
pulled it up to AssemblerBase and gave it an implementation that 
should work for the other architectures.

Also checked that ia32, x87, arm and arm64 assemblers didn't have 
such an implementation - free Print. 

Arm64 has a naming conflict with the v8::internal::Disassembler. I
renamed the arm64 type with a more specific name.

Opportunistically fixed a bug in the name converter. This debug-time
printer doesn't provide a Code object, which should be OK with the 
name converters, by the looks of other APIs there. All this means is that
when using the Print() API, we just get addresses dumped without any
context (like what this address may be - a stub maybe, etc). This seems
fine for the scenario.

There may be other places that assume a Code object. Since this is
a diagnostics-only scenario, for codegen developers, I feel it is 
reasonable to fix such other places as we find them.
 
BUG=
==========

[Benedikt Meurer, 2015-11-09 04:47:21]

Description was changed from

==========
Macro assembler debuggability.

While working on frame elision, I wanted to disassemble codegen in the 
debugger, as the code generation is progressing. I discovered we had a
 "Print" member on the x64 assembler, without any implementation. I 
pulled it up to AssemblerBase and gave it an implementation that 
should work for the other architectures.

Also checked that ia32, x87, arm and arm64 assemblers didn't have 
such an implementation - free Print. 

Arm64 has a naming conflict with the v8::internal::Disassembler. I
renamed the arm64 type with a more specific name.

Opportunistically fixed a bug in the name converter. This debug-time
printer doesn't provide a Code object, which should be OK with the 
name converters, by the looks of other APIs there. All this means is that
when using the Print() API, we just get addresses dumped without any
context (like what this address may be - a stub maybe, etc). This seems
fine for the scenario.

There may be other places that assume a Code object. Since this is
a diagnostics-only scenario, for codegen developers, I feel it is 
reasonable to fix such other places as we find them.
 
BUG=
==========

to

==========
[assembler] Introduce proper AssemblerBase::Print() for improved debuggability.

While working on frame elision, I wanted to disassemble codegen in the 
debugger, as the code generation is progressing. I discovered we had a
 "Print" member on the x64 assembler, without any implementation. I 
pulled it up to AssemblerBase and gave it an implementation that 
should work for the other architectures.

Also checked that ia32, x87, arm and arm64 assemblers didn't have 
such an implementation - free Print. 

Arm64 has a naming conflict with the v8::internal::Disassembler. I
renamed the arm64 type with a more specific name.

Opportunistically fixed a bug in the name converter. This debug-time
printer doesn't provide a Code object, which should be OK with the 
name converters, by the looks of other APIs there. All this means is that
when using the Print() API, we just get addresses dumped without any
context (like what this address may be - a stub maybe, etc). This seems
fine for the scenario.

There may be other places that assume a Code object. Since this is
a diagnostics-only scenario, for codegen developers, I feel it is 
reasonable to fix such other places as we find them.
==========

[Benedikt Meurer, 2015-11-09 04:48:02]

LGTM, thanks.

[Mircea Trofin, 2015-11-09 05:38:07]

The CQ bit was checked by mtrofin@chromium.org

[commit-bot: I haz the power, 2015-11-09 05:38:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1431933003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1431933003/20001

[commit-bot: I haz the power, 2015-11-09 05:39:25]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-11-09 05:39:57]

Patchset 2 (id:??) landed as
https://crrev.com/ab1d270a72a2c0553eb0b7d47eb6fa16ecc038c6
Cr-Commit-Position: refs/heads/master@{#31869}