search

Storyyeller / Krakatau

Java decompiler, assembler, and disassembler
GNU General Public License v3.0
1.95k stars 219 forks source link

Krakatau does not generate local variables info #188

Closed airbagi closed 1 year ago

airbagi commented 1 year ago

When decompiling, sometimes, decompiler generates local variables info, sometimes - not. What it depends on? How it can be fixed?

Is there any possibility to create local variables even when no "-g" compilation flag supplied? Using "store" or "load" directives?

thanks

Storyyeller commented 1 year ago

What do you mean by "generated local variables info"? The decompiler ignores LocalVariableTable/LocalVariableTypeTable attributes since they may not be present and can't be trusted even if they are.

airbagi commented 1 year ago

Why can't be trusted? I mean I want to work with classes within JDB, but without local variablt info its just informless. And I can say, that in some cases, decompiler generates this section. In others - don't. I can't understand reasons.

Janmm14 commented 1 year ago

Why can't be trusted? I mean I want to work with classes within JDB, but without local variablt info its just informless. And I can say, that in some cases, decompiler generates this section. In others - don't. I can't understand reasons.

A DEcompiler does not "generate" local variable names. A compiler can do this, krakatau is not a compiler. If you want code decompilation which uses local variable name information, choose another decompiler like CFR.

Please also note that there is a huge difference between local variable names and field names.

Krakatau decompiler's main goal is to decompile even obfuscated java to semantically equivalent java. Thats why it does not use potentially available local variable names - they can be wrong, identical for nonidentical locals or an annoying java keyword like "this".

airbagi commented 1 year ago

Why can't be trusted? I mean I want to work with classes within JDB, but without local variablt info its just informless. And I can say, that in some cases, decompiler generates this section. In others - don't. I can't understand reasons.

A DEcompiler does not "generate" local variable names. A compiler can do this, krakatau is not a compiler. If you want code decompilation which uses local variable name information, choose another decompiler like CFR.

Please also note that there is a huge difference between local variable names and field names.

Krakatau decompiler's main goal is to decompile even obfuscated java to semantically equivalent java. Thats why it does not use potentially available local variable names - they can be wrong, identical for nonidentical locals or an annoying java keyword like "this".

I understant the difference between field names and local variables. When I compile code with "-g" option I get local variables inside class file. DEcompiler gets this data (sometimes) and put it into j files. Sometimes not.

You suggest CFR, but how I will comile CFR decompiled files back to class or jar format? My goal is to add localvariables information into the class in order to use them upon debugging. I understand that DEcompiler does not generate local variable table, but this is not a problem.

Storyyeller commented 1 year ago

You can't re-compile decompiled code in general. You can do transformations like that a lot more reliably at the bytecode level.