On Wed, Jul 12, 2017 at 04:21:11PM -0400, Dale Rahn wrote:
> On Wed, Jul 12, 2017 at 11:06:23PM +0300, Artturi Alm wrote:
> > On Wed, Jul 12, 2017 at 06:12:34PM +0200, Mark Kettenis wrote:
> > > > Date: Mon, 10 Jul 2017 23:18:59 +0300
> > > > From: Artturi Alm <artturi....@gmail.com>
> > > > 
> > > > Hi,
> > > > 
> > > > this does clutter my diffs, and the XXX comment is correct,
> > > 
> > > It probably isn't. None of the other architectures have those macros
> > > in their <machine/asm.h>.
> > > 
> > 
> > Ok, didn't consider that, you're right and the diff withdrawn, but anyway,
> > what i was imprecisely after was that i'd prefer
> > having something like RODATA(name) found from sparc64/include/asm.h,
> > instead of the useless _C_LABEL() to use in armv7 md .S assembly, and
> > just because of the weird name i didn't find intuitive enough, i didn't
> > even suggest the arm64 EENTRY()..
> > Don't get me wrong, i'm more than happy to drop all the labeling
> > macros out of my diffs, and choose my self what is global and what is not,
> > while it's against the minimalism i'm now aiming at to even get the diffs
> > read&commented when freetime&interest does meet:)
> 
> _C_LABEL() is a holdover from the pre-ELF days. At one time (in NetBSD)
> this code still compiled using an a.out toolchain. In that era, it was
> defined to be _C_LABEL(x) _/**/x (this was also pre-ansi)
> (or _ ## x post ansi). On ELF _C_LABEL evaluates to just the symbol. It
> cannot have any association to either text or data because the proper use
> of it can refer to either text or data eg: bl _C_LABEL(c_func).
> 
> Basically it is a relic from the past, it might make sense to just remove
> all references to _C_LABEL() at this point and just the symbol itself.
> 
> Dale Rahn                             dr...@dalerahn.com

Oh, that explains what i was missing about 'why?', thank you for the info/
details.
At this point, given how harmless it is, i think cleaning up all at once
would be just churn, so i will consider it deprecated myself, and go w/o
it in my future diffs, which would touch any of them for other reasons.

-Artturi

Reply via email to