subclassing MCELFStreamer

Project Infrastructure LLVM Dev List Archives
#1

Hi Jim, Daniel,

The last time the topic of subclassing MCELFStreamer came up, you both were
helpful in identifying ways to handle the use case without requiring
subclassing. Can you please take a look at the context below and let me know
if you have any suggestions?

For reference, this was posted to the list yesterday under the subject
"sub-classing MCObjectStreamer?":

Okay, after more careful scrutiny of the code I see that MCObjectStreamer

is

intended to be very generic and it would actually be MCELFStreamer that I

would

need to subclass. I see from a search through the dev list that this was

discussed

previously and discouraged, so I'll provide more context.

We are working on integrated and stand-alone assemblers for a VLIW target
(Hexagon) and need to apply, among other things, instruction ordering

rules on a

per-packet basis. We could handle this in the lowering phase, but the

standalone

assembly parser goes straight to MC and bypasses the lowering pass

altogether.

This means we need to be able to work with packets in the streamer.

We could easily address this by subclassing the streamer, but this seems

to be

discouraged as far as I can tell. Can we subclass MCELFStreamer to suit

our

needs, or are there other ways to handle this case?

Thanks,
- --
Mario Guerra
mariog@codeaurora.org
Qualcomm Innovation Center Inc is a member of Code Aurora Forum, hosted by
The Linux Foundation

#2

Hi Mario,

The last time the topic of subclassing MCELFStreamer came up, you both were
helpful in identifying ways to handle the use case without requiring
subclassing. Can you please take a look at the context below and let me know
if you have any suggestions?

Subclassing MCELFStreamer is probably also necessary to implement
mapping symbols on ARM ELF targets (see the current thread at
http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/124737).

Your refactoring patch on phabricator appears to be a functional
subset of the one I've posted (though obviously not textually
identical). As a smaller patch, it may be best to commit that first
unless there are objections.

Tim.

#3

Subclassing MCELFStreamer is probably also necessary to implement mapping
symbols on ARM ELF targets (see the current thread at
http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/124737).

Your refactoring patch on phabricator appears to be a functional subset of

the one

I've posted (though obviously not textually identical). As a smaller

patch, it may be

best to commit that first unless there are objections.

Thanks for your reply Tim. Reading through the thread, it would seem that
subclassing MCELFStreamer is not exactly desirable, but doable when
necessary. I'm going to follow this approach, unless anyone has any major
objections?

Thanks,
Mario

#4

In my ARM EHABI work, I have to subclass the MCELFStreamer to
split ARM-related code into Target/ARM. I’d like to know if there is
any objection as well.

Thanks.
Logan

FYI. http://llvm.org/bugs/show_bug.cgi?id=7187