search for: address_safety

...to test it. In most cases I've met so far, the developers decided to actually fix the bugs according to the C++ standard and require the memory allocation to have up to 7 extra bytes. I do expect that sometimes this is impossible or undesirable. Then the solution would be to use __attribute__((address_safety)) to avoid instrumenting the tricky pieces of code. --kcc just like the optimizers, they know it is safe and a win. > The attribute won't help them. It looks like a way of just hiding the real > problem, which seems to be that address sanitizer is overly strict. > > ------------...

...ly the C standard is not relevant to LLVM IR coming from such languages. What matters is how LLVM IR is defined. As far as I know this construct is perfectly valid in LLVM IR. > I do expect that sometimes this is impossible or undesirable. > Then the solution would be to use __attribute__((address_safety)) to avoid > instrumenting the tricky pieces of code. Unfortunately there is in general no way of attaching such attributes in many languages. Ciao, Duncan. > > --kcc > > > just like the optimizers, they know it is safe and a win. > The attribute won't help them....

...): -- /Users/partigas/Desktop/src/llvm/test/Instrumentation/AddressSanitizer/instrument_initializer_metadata.ll:33:10: error: expected string not found in input ; CHECK: call void @__asan_before_dynamic_init ^ <stdin>:20:35: note: scanning from here define internal void @_GLOBAL__I_a() address_safety section ".text.startup" { ^ <stdin>:33:3: note: possible intended match here declare void @__asan_report_load1(i64) ^ -- I presume this is either a bug (as the ordering of the doInitialization/doFinalization per module should not matter as they are j...

...: -- /Users/partigas/Desktop/src/llvm/test/Instrumentation/AddressSanitizer/instrument_initializer_metadata.ll:33:10: error: expected string not found in input ; CHECK: call void @__asan_before_dynamic_init ^ <stdin>:20:35: note: scanning from here define internal void @_GLOBAL__I_a() address_safety section ".text.startup" { ^ <stdin>:33:3: note: possible intended match here declare void @__asan_report_load1(i64) ^ -- I presume this is either a bug (as the ordering of the doInitialization/doFinalization per module should not matter as they are...

Hi Kostya, > [resurrecting an old mail thread about AddressSanitizer false positive caused by > load widening] > > Once the Attribute::AddressSafety is set by clang (a separate patch), fixing > this bug may look as simple as this: I don't get the point of an attribute. There's plenty of code out there that does wide loads like this directly (without them being created by

...rary heavily depends on the C/C++ semantics and even implementation, and you can't really separate the asan instrumentation pass from the run-time. --kcc > > > I do expect that sometimes this is impossible or undesirable. >> Then the solution would be to use __attribute__((address_safety)**) to >> avoid >> instrumenting the tricky pieces of code. >> > > Unfortunately there is in general no way of attaching such attributes in > many > languages. > > Ciao, Duncan. > > > >> --kcc >> >> >> just like the optimizers,...