On Wed, Jul 18, 2018 at 8:01 AM, Pablo Alvarez via Lists.Iovisor.Org
<[email protected]> wrote:
> Hi Daniel,
>
> Yes. If you look at the bug report, you will see that what it actually
> returns is some form of the increment. that is,
>
> __sync_add_and_fetch(myptr, increment)
>
> returns either increment or (increment * 2) (I am not sure which right now)
>
> The fact that other builtins don't compile with LLVM is not too
> surprising, given that it's a very restricted subset of C. The fact that
> something does compile but then does not produce the promised result...
> that's a little more of an issue!
>
> Are there people on this list who have worked on the LLVM BPF compiler?
> I might be willing to try to tackle fixing the bug, but I would need
> some guidance...

Pablo,

I added the below comment in the bug report:

===

The table description for bpf_xadd operation is at BPFInstrInfo.td:

// Atomics
class XADD<BPFWidthModifer SizeOp, string OpcodeStr, PatFrag OpNode>
    : TYPE_LD_ST<BPF_XADD.Value, SizeOp.Value,
                 (outs GPR:$dst),
                 (ins MEMri:$addr, GPR:$val),
                 "lock *("#OpcodeStr#" *)($addr) += $val",
                 [(set GPR:$dst, (OpNode ADDRri:$addr, GPR:$val))]> {
  bits<4> dst;
  bits<20> addr;

  let Inst{51-48} = addr{19-16}; // base reg
  let Inst{55-52} = dst;
  let Inst{47-32} = addr{15-0}; // offset
  let BPFClass = BPF_STX;
}

let Constraints = "$dst = $val" in {
def XADD32 : XADD<BPF_W, "u32", atomic_load_add_32>;
def XADD64 : XADD<BPF_DW, "u64", atomic_load_add_64>;
// undefined def XADD16 : XADD<1, "xadd16", atomic_load_add_16>;
// undefined def XADD8  : XADD<2, "xadd8", atomic_load_add_8>;
}
===

Please feel free to take a look how to address this issue.
I can help discussion/review along the way.

Thanks!

Yonghong


>
> Best
>
> Pablo Alvarez
>
> On 07/18/18 09:27, Daniel Zozin wrote:
>> Hi Pablo,
>> I'm facing the same problem by compiling and running on kernel 4.15.
>> Calls to __sync_fetch_and_add keeps returning the same value while the
>> actual value has been incremented.
>> Also I add __sync_val_compare_and_swap to your list of primitives
>> generating compiling errors.
>>
>> I Investigated a bit but I have no clue on how this can be fixed.
>>
>> Daniel
>>
>> On Wed, Jul 18, 2018 at 1:46 PM, Pablo Alvarez via Lists.Iovisor.Org
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__Lists.Iovisor.Org&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=0Y4-Ozye8rzL2OdOod5_xTXo5tWHsrs0CqSpjE-K1PQ&e=>
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>     Hi all,
>>
>>     A while ago, I filed a bug with LLVM about __sync_add_and_fetch as
>>     compiled into eBPF code.
>>
>>     https://bugs.llvm.org/show_bug.cgi?id=36573
>>     
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D36573&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=A4pMWnUIf29oD7glNQD3MEAAX27WhbV-L7TCaM9koNk&e=>
>>
>>     Both it and __sync_fetch_and_add fail to return the correct value of
>>     the item being incremented, returning instead the increment (or
>>     double the increment). This means I end up with race conditions. Has
>>     anyone else run into this, and do you have a workaround for it?
>>
>>     The bug report, sadly, has not been touched by anyone else.
>>
>>     Best
>>
>>     Pablo Alvarez
>>
>>
>>
>>
>>
>>
>> --
>> Daniel Zozin, Dr.
>> Research Engineer
>> RiSING - Robust and Secure Distributed Computing
>> ----------------------------------------
>> CREATE-NET Research Center
>> Fondazione Bruno Kessler (FBK)
>> via alla Cascata 56D
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstreetmap.org_search-3Fquery-3D46.07056-252C11.15092-23map-3D19_46.07056_11.15092-26layers-3DN&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=dk6ixv2SUmNaTT-TrXohRsrqnojkqI89jO8eHVMFhbM&e=>
>> 38123 Povo, Trento (Italy)
>> Tel.: +39 0461 312480
>> e-mail: [email protected] <mailto:[email protected]>
>> www: https://create-net.fbk.eu/
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__create-2Dnet.fbk.eu_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=HU2BzKZl_Wb0rxi6vLbplXVWa-e4N2f1PD3e82TAk28&e=>
>> GPG KEY: 0x6F66193EC7034588
>>
>> --
>> Le informazioni contenute nella presente comunicazione sono di
>> natura privata e come tali sono da considerarsi riservate ed
>> indirizzate esclusivamente ai destinatari indicati e per le finalitĂ 
>> strettamente legate al relativo contenuto. Se avete ricevuto questo
>> messaggio per errore, vi preghiamo di eliminarlo e di inviare una
>> comunicazione all’indirizzo e-mail del mittente.
>> --
>> The information transmitted is intended only for the person or entity to
>> which it is addressed and may contain confidential and/or privileged
>> material. If you received this in error, please contact the sender and
>> delete the material.
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#1387): https://lists.iovisor.org/g/iovisor-dev/message/1387
Mute This Topic: https://lists.iovisor.org/mt/23670176/21656
Group Owner: [email protected]
Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub  
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to