lkml.org 
[lkml]   [2017]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

* Jiri Slaby <jslaby@suse.cz> wrote:

> On 03/22/2017, 08:25 AM, Ingo Molnar wrote:
> >
> > * Pavel Machek <pavel@ucw.cz> wrote:
> >
> >> Hi!
> >>
> >>> -ENTRY(saved_rbp) .quad 0
> >>> -ENTRY(saved_rsi) .quad 0
> >>> -ENTRY(saved_rdi) .quad 0
> >>> -ENTRY(saved_rbx) .quad 0
> >>> +SYM_DATA_START(saved_rbp) .quad 0
> >>> +SYM_DATA_START(saved_rsi) .quad 0
> >>> +SYM_DATA_START(saved_rdi) .quad 0
> >>> +SYM_DATA_START(saved_rbx) .quad 0
> >>
> >> Does it make sense to call it SYM_DATA_*START* when there's no
> >> corresponding end?
> >
> > That looks like a bug - I think we should strive for them to always be in pairs.
> >
> > Jiri, Josh, could objtool help here perhaps, to detect 'non-terminated'
> > SYM_*_START() uses? This could be done by emitting debug data into a special
> > section and then analyzing that section for unpaired entries. The section can be
> > discarded in the final link, it won't show up in the kernel image.
>
> It should be easier than that. No introduction of other info needed --
> every global symbol without a ".type" or ".size" (i.e. SYM_*_END) should
> be a bug now.

I'm all for that!

Can we detect double ends as well - i.e. do a build check of the full syntax of
these symbol definition primitives?

Thanks,

Ingo

\
 
 \ /
  Last update: 2017-03-22 08:47    [W:0.139 / U:0.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site