ARM mapping symbols interpreted incorrectly when using 'Combine text sections'

[akiramusic000]

When using ELF ARM object files, objdiff uses a type of symbol called a "mapping symbol" to determine whether a section of code is ARM, Thumb, or data. The mapping symbols affect bytes from their location in the section until the next mapping symbol, or the end of the section. However, when using the 'Combine text sections' option, the separation between sections is lost, and a mapping symbol at address 0 of section A will affect bytes at address 0 of section B, as shown:

The last $d symbol is at address 18, which is also where nn::svc::CreateAddressArbiter is placed. Because of this, the code of nn::svc::CreateAddressArbiter is interpreted all as data:

However, when not using Combine text sections, this works as intended, and the function is interpreted as ARM code:

[LagoLunatic]

Can you upload an example object file where this happens? I've used combine text sections with ARM ELFs before but I don't think I've encountered one where a mapping symbol from one section wound up at the same address as a function from another section.

[akiramusic000]

Sure, this is the one in the screenshots.
svc.o.zip

[akiramusic000]

My guess after messing around with the code a bit is that when Combine text section is on, it modifies the section indexes to all be the same. Not completely sure, but that seems likely.

[akiramusic000]

Yep, this is the culprit:

objdiff/objdiff-core/src/obj/read.rs

Line 948 in 73917c1

let first_section_idx = section_indices[0];

[LagoLunatic]

Sure, this is the one in the screenshots.
svc.o.zip

Thanks. It's strange that a function with no data pool has a $d mapping symbol. In my experience MWCC does not emit a $d in that case. Example:

I guess it's probably a rare bug in MWCC, I assume you don't know what triggers it?

My guess after messing around with the code a bit is that when Combine text section is on, it modifies the section indexes to all be the same. Not completely sure, but that seems likely.

Right, that's the part that makes the symbols combine into the first section, without it they would be in separate sections as if you didn't enable the option.

[akiramusic000]

Thanks. It's strange that a function with no data pool has a $d mapping symbol. In my experience MWCC does not emit a $d in that case.

It's not MWCC, the object is from a splitting script that I wrote. Now that I think about it, I could fix it temporarily by not emitting $d symbols at the end of functions, but I do still think this is a bug that should be fixed, or at least known.

[LagoLunatic]

It's not MWCC, the object is from a splitting script that I wrote. Now that I think about it, I could fix it temporarily by not emitting $d symbols at the end of functions, but I do still think this is a bug that should be fixed, or at least known.

I see, in that case it might be better to consider this a bug in the script instead of objdiff if MWCC never does this itself.

It would theoretically be possible to add a workaround in objdiff to specifically delete $d symbols located at the end of a section when sections are combined, but this would require adding ARM-specific code to the combine functions. Currently those functions are arch-agnostic.

[akiramusic000]

I see, in that case it might be better to consider this a bug in the script instead of objdiff if MWCC never does this itself.

While the script is definitely part of the problem, I would argue that the root cause is objdiff. When ELF files are created, they don't expect separate sections to be combined into one section, no matter how the file is generated.

It would theoretically be possible to add a workaround in objdiff to specifically delete $d symbols located at the end of a section when sections are combined, but this would require adding ARM-specific code to the combine functions. Currently those functions are arch-agnostic.

One way to fix it would be to add an 'original section index' field to Symbol, and then compare that with the section index in the code for ARM (scan_instructions_internal). However, the original section index of the section being parsed would also have to be passed to that function, which could get messy.