[LLVMdev] bit code file incompatibility due to debug info changes

[Manman Ren]

>> >>>
> >> >>> Except we'd never actually need to merge the flag - since we would
> >> >>> drop
> >> >>> it from any module that didn't have the latest, right? I'm not sure
> >> >>> this
> >> >>> would need to be a module flag, then, since there would be no need
> to
> >> >>> define
> >> >>> merging behavior. Is there an advantage to using a module flag over
> >> >>> just
> >> >>> putting it on the compile unit metadata node somewhere?
> >> >>
> >> >>
> >> >> Agreed. So we have two choices here, use a module flag and remove the
> >> >> module flag when stripping the debug info, so we will never merge
> >> >> modules
> >> >> with different debug info versions. (no new mode is required)
> >> >>
> >> >> The other choice is putting it on the compile unit MDNode as a field.
> >> >> There is no reliable way of checking if an old bc file has a version
> >> >> number, because it requires parsing the CU MDNodes in the old bc
> files.
> >> >> Also if we are not going to support multiple debug info versions in a
> >> >> single compiler, there is no point of putting a version number in
> each
> >> >> CU
> >> >> MDNode.
> >> >
> >> >
> >> > Fair point. Any useful tradeoffs to consider between a single named
> >> > MDNode
> >> > and a module flag?
> >> >
> >>
> >> Probably simplicity at the moment. A module flag is pretty easy to
> >> read/parse/etc at load time versus having to put it in the metadata
> >> itself.
> >
> >
> > If the module flag is easier - I'm all for it. I wasn't sure if they were
> > schematized more strictly than metadata or anything.
> >
> >>
> >> In the metadata itself though we'd have everything self
> >> contained (i.e. just stick it as a field on the compile unit or
> >> something).
> >
> >
> > I'm with Manman on the "if we never have mismatched versions, paying a
> > per-CU overhead is silly" position, so I'd put it in its own named
> metadata
> > instead (since necessarily anything other than the loading code would
> never
> > see CUs with anything other than the current debug version, so it would
> be
> > entirely redundant) - but sounds like module is simpler, so that's great.
> >
>
> Lots of agreement here. :)


Great that we reach agreement :)
I will start adding the module flag and updating the testing cases.

Thanks,
Manman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131122/e9dd660e/attachment.html>