Skip to content

Add o segment type#520

Open
mkst wants to merge 3 commits intomainfrom
add-o-segment
Open

Add o segment type#520
mkst wants to merge 3 commits intomainfrom
add-o-segment

Conversation

@mkst
Copy link
Collaborator

@mkst mkst commented Feb 26, 2026

If there's a way to do this already im all ears.. but this is more granular than using the lib segment (and I am struggling to link against libultra.a in a piecemeal fashion, so just wanted to cherry-pick individual objects from it)

@emoose
Copy link

emoose commented Feb 27, 2026

fyi in SH there was some issue with this line:
out_path = options.opts.build_path / f"{self.name}"
for [0x1234, o, lib/libthing/obj] that would output build/src/lib/libthing/obj.o in the ld, but some reason even using [0x1234, o, ../../lib/libthing/obj] would still result in build/src/lib/libthing too, not really sure why the ../ got ignored.

In your o.py extension I changed to out_path = Path(f"{self.name}"), and that let the ../../ start to work (though not really sure why that ../../ was still needed for it?)

(also when we were using [0x1234, lib, lib/libthing, obj], that was able to pull from our repo root instead of using build/src/ folders, maybe something can be copied from the lib segment handler?)

@mkst
Copy link
Collaborator Author

mkst commented Feb 27, 2026

For the lib segment there is an explicit splat setting for the lib directory (rather than using the build_dir).

You can do a simple cp in your makefile to move objects into the build directory... I think it's more correct that these .o files are expected to be "built"

@emoose
Copy link

emoose commented Feb 27, 2026

Ah right, guess for us lib_dir had just defaulted to repo root then.

I think it's more correct that these .o files are expected to be "built"

Makes sense, I don't mind adding a copy to the build dir for it, was just a bit surprised that using ../ wasn't seeming to have any affect at all, can't really see what would even be stopping that, odd.

@ethteck ethteck requested a review from AngheloAlf March 3, 2026 10:11
@ethteck
Copy link
Owner

ethteck commented Mar 3, 2026

could you bump the version (there's 3 places, you can find/replace it) and add to the changelog?


```yaml
# link to .text of myobject.o
- [auto, o, myobject]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think recommending auto for this segment type would be a great idea, because it could mess up the size calculation of the previous subsegment. This can be problematic if people wants to disassemble the previous subsegment while linking this object.


# Should be synced with pyproject.toml
__version__ = "0.38.0"
__version__ = "0.38.1"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This introduces a new feature so this should be bumped to 0.39.0 instead of just a patch bump


## `o`

Similar to the `lib` segment but used to reference an object file (for example extracted from a shared library file). Does not extract anything from the input binary.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to mention that this segment can only be used as a subsegment and not as a top-level segment.

Also, where is the object expected to be? In the build folder? Relative to the src, asm, lib, etc folder?
Maybe we should introduce a new setting for this? Something like o_path

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants