arm-poky-linux-gnueabi-g++ and O_DIRECT flag...

All design tool related questions: compiler, assembler, linker. Embedded programming questions: assembler, C code.

Moderator: nferre

Posts: 11
Joined: Sat May 24, 2014 5:33 am

arm-poky-linux-gnueabi-g++ and O_DIRECT flag...

Sun Sep 07, 2014 6:46 am

I'm using sama5d3_xplained, and YOCTO setting to generate the cross-tools, images, etc... 
Everything seemed to work fine, until  I tried to add the O_DIRECT flag to open()...

The compiler behaviour really puzzles me. May be somebody can give an idea where/what to check... 
I'm observing the following:

1. The code:
#include <fcntl.h>
int main(void){
unsigned t1;
    t1 =  O_DIRECT;
2. The above is the fragment of .cpp file, generated by eclipse,  with 'hello, world' 'template'.
The programme can be compiled, linked,  can be downloaded to the board via remote debug, traced...  So far  everything looks  good. 

3. Disassembling the line  -  t1 = O_DIRECT - shows:
   'mov r3, #65536'
   ( And indeed, after line execution, t1 is set to 0x10000)

   But, at the same time -- open O_DIRECT diclaration  shows
   #define O_DIRECT  __O_DIRECT
   where, __O_DIRECT in its turn 
  #define __O_DIRECT 040000

  Based on that, the expected value of the t1 should be 0x4000;
  ( Actually, macro expansion tool within eclipse ADT, is also showing above steps of expansion -  O_DIRECT -> __O_DIRECT -> 040000 - and 'predicts' the value  to be 040000....) 
   But actual assembly -- and execution -- shows 0x10000.

As the project build goes, the arm-poky-linux-gnueabi-g++  does not make any complains. 

I would really appreciate any idea on what to double check and what to look at. 


Posts: 1
Joined: Sun Sep 07, 2014 1:22 pm

Re: arm-poky-linux-gnueabi-g++ and O_DIRECT flag...

Sun Sep 07, 2014 1:27 pm


It is not clear to me the type of variable 't1'. 
In your code you declare it only as unsigned.
Are you sure this is not a casting issue?
Posts: 11
Joined: Sat May 24, 2014 5:33 am

Re: arm-poky-linux-gnueabi-g++ and O_DIRECT flag...

Mon Sep 08, 2014 12:55 am

While tracing the problem:    
1. I used  'g++ -E -dD -dI -P testODIR.cpp'  to generate the list of macros. 
I found where the 0200000 assignment  is coming from:

.../sysroot/sama5d3_xplained/usr/include/fcntl.h --->
And the latest file has the definition 
#define __O_DIRECT 0200000

2. The assignment of O_DIRECT is happening within
# define  O_DIRECT __O_DIRECT... 
 A bit before O_DIRECT is assigned, within the same fcntl-linux.h,
there is another code:
#ifndef __O_DIRECT
# define __O_DIRECT 040000
(And that is the line, which Eclipse shows when 'Open declaration' is used... 
But apparently, since the __O_DIRECT has been already defined to 0200000, the #ifndef is not involved... )

So, what compiler is doing is more or less clear now.... 

3. Now, my next question is --> what the actual number should be? 
The problem is:
-  If the number 0200000 is used as O_DIRECT, then the open(...) call returns invalid parameter;
- if the number 0x4000 is used as O_DIRECT, then the open(..) call returns success.

So, I wonder why the actual settings for O_DIRECT  and  'default' ( within #ifndef ...) are so different? 
And also, which file should I check within linux kernel itself, to see which was actually used while the kernel was build?
But that is probably the question to the sam5e3_xplained group, how the O_DIRECT has been implemented...

Return to “Development Tools”

Who is online

Users browsing this forum: No registered users and 1 guest