llvm dev - Mar 2016 - Undefined behaviour in command line parser

In these days I’ve integrated llc code into my compiler.

I had an undefined behaviour because when
cl::AddExtraVersionPrinter(TargetRegistry::printRegisteredTargetsForVersion) is
called, the modules I give to the code in input to compile got somehow
“corrupted" by this function.
It is definitely an undefined behaviour because every debug I do, modules gets
different changes, producing different assertions every run:

- Target triple string gets changes with null characters
(“\0\0\0\0\0\0\0\0\0\0\0”), or other values that have nothing to do with an llvm
triple
- Head of the function list contained in the module becomes NULL (I said
functions but maybe other components may be nullified as well)

I tried to see where the modules change, and I figured out that 6/10 times the
target triple is ok before that instruction, then it takes weird changes after
it.
The problem is that function because when I removed it, everything worked fine.

I didn't figure out how that function may change modules that way, so I just
report this bug here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160327/f669cc35/attachment.html>

Hi Lorenzo,

Thanks for the report. Can you create a new entry in Bugzilla? With
steps to reproduce (command line options, etc) and how you're getting
the value of the triple (debugger?).

http://llvm.org/bugs/

cheers,
--renato

On 27 March 2016 at 17:15, Lorenzo Laneve via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> In these days I’ve integrated llc code into my compiler.
>
> I had an undefined behaviour because when
>
cl::AddExtraVersionPrinter(TargetRegistry::printRegisteredTargetsForVersion)
> is called, the modules I give to the code in input to compile got somehow
> “corrupted" by this function.
> It is definitely an undefined behaviour because every debug I do, modules
> gets different changes, producing different assertions every run:
>
> - Target triple string gets changes with null characters
> (“\0\0\0\0\0\0\0\0\0\0\0”), or other values that have nothing to do with an
> llvm triple
> - Head of the function list contained in the module becomes NULL (I said
> functions but maybe other components may be nullified as well)
>
> I tried to see where the modules change, and I figured out that 6/10 times
> the target triple is ok before that instruction, then it takes weird
changes
> after it.
> The problem is that function because when I removed it, everything worked
> fine.
>
> I didn't figure out how that function may change modules that way, so I
just
> report this bug here.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

Done, I added as much info as I could that describes how I got that behavior.
> On Mar 27, 2016, at 7:40 PM, Renato Golin <renato.golin at
linaro.org> wrote:
> 
> Hi Lorenzo,
> 
> Thanks for the report. Can you create a new entry in Bugzilla? With
> steps to reproduce (command line options, etc) and how you're getting
> the value of the triple (debugger?).
> 
> http://llvm.org/bugs/
> 
> cheers,
> --renato
> 
> On 27 March 2016 at 17:15, Lorenzo Laneve via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> In these days I’ve integrated llc code into my compiler.
>> 
>> I had an undefined behaviour because when
>>
cl::AddExtraVersionPrinter(TargetRegistry::printRegisteredTargetsForVersion)
>> is called, the modules I give to the code in input to compile got
somehow
>> “corrupted" by this function.
>> It is definitely an undefined behaviour because every debug I do,
modules
>> gets different changes, producing different assertions every run:
>> 
>> - Target triple string gets changes with null characters
>> (“\0\0\0\0\0\0\0\0\0\0\0”), or other values that have nothing to do
with an
>> llvm triple
>> - Head of the function list contained in the module becomes NULL (I
said
>> functions but maybe other components may be nullified as well)
>> 
>> I tried to see where the modules change, and I figured out that 6/10
times
>> the target triple is ok before that instruction, then it takes weird
changes
>> after it.
>> The problem is that function because when I removed it, everything
worked
>> fine.
>> 
>> I didn't figure out how that function may change modules that way,
so I just
>> report this bug here.
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>