[llvm-commits] [llvm] r172630 - in /llvm/trunk: include/llvm/MC/MCContext.h lib/MC/MCDwarf.cpp test/MC/MachO/gen-dwarf-producer.s tools/llvm-mc/llvm-mc.cpp

[Kevin Enderby]

On Jan 16, 2013, at 10:44 AM, Eric Christopher <echristo at gmail.com> wrote:

> 
> 
> 
> On Wed, Jan 16, 2013 at 10:38 AM, David Blaikie <dblaikie at gmail.com> wrote:
> On Wed, Jan 16, 2013 at 9:55 AM, Kevin Enderby <enderby at apple.com> wrote:
> > Hi Eric,
> >
> > This is just for testing (without the clang change).  I didn't want to add a
> > it as a command line argument to llvm-mc as that would then have the
> > producer string as it would also affect the AT_Apple flags.
> 
> Curious: what do you mean by this? What are the AT_Apple flags?
> (sorry, I'm not familiar with this area)
> 
> 
> There are some apple internal attributes on dwarf. They're usually tagged DW_AT_APPLE_...
>  
> As for the testing issue, could this be written as a unit test instead
> of having a test hook like this? (Ideally even once Clang is testing
> this code path, it'd be nice to still have LLVM functionality tested
> in LLVM so LLVM developers who aren't necessarily working
> with/building/testing Clang could still know that they haven't broken
> this functionality - but I realize sometimes that benefit isn't worth
> the overhead of writing such tests for relatively trivial features,
> but it's worth checking* if we've reached a tipping point where a few
> trivial features could all benefit from the addition of unit tests,
> for example)
> 
> * I say this in the absence of any specific knowledge - perhaps this
> is the only such case & there's no aggregate benefit, etc, at the
> moment.
> 
> 
> Not necessarily a bad idea. The code path could alternately be tested by a command line flag added to llvm-mc?

Again I didn't want to add a command line to llvm-mc as it would effect the values in the DW_AT_APPLE since it contains all the command line.
> 
> 
> Kevin? Your thoughts?

I really don't care how this is tested.  I just want to get the work done.

> 
> -eric
>  
> >
> > If you like I can remove this code and the test when the clang side of the
> > change is finished.
> >
> > Kev
> >
> > On Jan 16, 2013, at 9:52 AM, Eric Christopher <echristo at gmail.com> wrote:
> >
> >
> >
> >> +static std::string DwarfDebugProducer;
> >> +static void setDwarfDebugProducer(void) {
> >> +  if(!getenv("DEBUG_PRODUCER"))
> >> +    return;
> >> +  DwarfDebugProducer += getenv("DEBUG_PRODUCER");
> >> +}
> >> +
> >
> >
> > Any particular reason or compatibility with this? I'd prefer not to have it
> > otherwise. If we do need it can you make it work for the compiled case as
> > well?
> >
> > Thanks!
> >
> > -eric
> >
> >
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130116/99477163/attachment.html>