RFR: 7439: Introduced IConstantPoolExtension for Constant Pools [v6]

[Michael Südkamp]

On Fri, 26 Nov 2021 20:46:41 GMT, Jean-Philippe Bempel <jpbempel at openjdk.org> wrote:

>> Add extension methods when constants are read, referenced, resolved, constant pools fully resolved and parsing finished to be able for example:
>> 
>>  * track constant pool usage inside events
>>  * replace or translate symbols, method names, etc... like
>> de-obfuscations of stack traces
>
> Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused import

Back to my real deobfuscation mapping, I found that of course I DID handle the package remapping there, but using real Proguard obfuscation mapping the situation is more complex (or real) than the demo I provided. 

When I debugged one of these StringIndexOutOfBoundsExceptions, I have this situation  in StructTypes.convertNames()

**name**=de.docware.apps.etk.base.db.cache.EtkDbsCacheElems, **getPackageName()**=de.docware.apps.etk.base.db.AbstractRevisionChangeSet

And these are the relevant entries from the Proguard mapping file.

de.docware.apps.etk.base.db.cache.EtkDbsCacheElems -> de.docware.apps.etk.base.d.a.e:
de.docware.apps.etk.base.db.AbstractRevisionChangeSet -> de.docware.apps.etk.base.d.a:

What I do obviously (or maybe naively) when I find a hit for ""de.docware.apps.etk.base.d.a.e", I assume "de.docware.apps.etk.base.d.a" to be the package name. But as you can see Proguard uses this String for another class mapping.
I can only guess but I think this can only work because Proguard obfuscates on byte code level. 

I haven't observed this problem with my existing deobfuscation solution on formatting level. Probably I was just interested in class and methods, and packages had no importance so far - that's why it worked there.

When I return to work I will discuss this with a smart colleague, but maybe we are stuck here.

-------------

PR: https://git.openjdk.java.net/jmc/pull/333