Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build error on x86, file dmaSendFd.h, line 85 #106

Open
chenm001 opened this issue Jan 17, 2016 · 8 comments
Open

build error on x86, file dmaSendFd.h, line 85 #106

chenm001 opened this issue Jan 17, 2016 · 8 comments

Comments

@chenm001
Copy link
Contributor

The addr is 32bits in x86 platform, the sg_phys() return dma_addr_t, it is mismatch to 'long'

@hanw
Copy link
Member

hanw commented Jan 17, 2016

can you post the error message?

@jankcorn
Copy link
Member

Are you sure that addr is 32 bits on x86? we always run 64-bit versions,
so seems peculiar.

In addition, I am accustomed to sizeof(long) == sizeof(void *), for
example, see the last line of the next-to-last paragraph of:
http://www.makelinux.net/ldd3/chp-11-sect-1
( was looking for this in the c std, but can't find similar text... :-( )

Thanks
jca

On Sun, Jan 17, 2016 at 9:00 AM, Han Wang notifications@github.com wrote:

can you post the error message?


Reply to this email directly or view it on GitHub
#106 (comment)
.

@chenm001
Copy link
Contributor Author

Below is error message, the problem is Shift 32 bits and OR with addr
btw: the dma_addr_t defined in Linux header, so it maybe 32 or 64bits depends OS configure.


prepare_bin_target
ubuntu.exe
cc1plus: warnings being treated as errors
In file included from /chen/connectal/cpp/dmaManager.c:35:
/chen/connectal/cpp/dmaSendFd.h: In function int send_fd_to_portal(PortalInternal_, int, int, int):
/chen/connectal/cpp/dmaSendFd.h:85: error: left shift count >= width of type
make[2]: *_* [ubuntu.exe] Error 1
make[1]: *** [ubuntu.exe] Error 2
make: *** [build.bluesim] Error 2
rhel:/connectal/examples/echo#
************* END **************************************

At 2016-01-18 01:18:10,jankcorn notifications@github.com wrote:
Are you sure that addr is 32 bits on x86? we always run 64-bit versions,
so seems peculiar.

In addition, I am accustomed to sizeof(long) == sizeof(void *), for
example, see the last line of the next-to-last paragraph of:
http://www.makelinux.net/ldd3/chp-11-sect-1
( was looking for this in the c std, but can't find similar text... :-( )

Thanks
jca

On Sun, Jan 17, 2016 at 9:00 AM, Han Wang notifications@github.com wrote:

can you post the error message?


Reply to this email directly or view it on GitHub
#106 (comment)
.


Reply to this email directly or view it on GitHub.

@jankcorn
Copy link
Member

I see. This is code only for simulations.
It appears that simulation builds (xsim, bluesim, modelsim, verilator) have
to be run on 64-bit architectures (which, in practice, are always x86).

I would highly recommend switching to a machine with a 64-bit OS. (since
the 32 bit os can't address much memory anyway for simulation...)

Is that possible?
jca

On Sun, Jan 17, 2016 at 9:54 PM, chenm001 notifications@github.com wrote:

Below is error message, the problem is Shift 32 bits and OR with addr
btw: the dma_addr_t defined in Linux header, so it maybe 32 or 64bits
depends OS configure.


prepare_bin_target
ubuntu.exe
cc1plus: warnings being treated as errors
In file included from /chen/connectal/cpp/dmaManager.c:35:
/chen/connectal/cpp/dmaSendFd.h: In function int
send_fd_to_portal(PortalInternal_, int, int, int):
/chen/connectal/cpp/dmaSendFd.h:85: error: left shift count >= width of
type
make[2]: *_* [ubuntu.exe] Error 1
make[1]: *** [ubuntu.exe] Error 2
make: *** [build.bluesim] Error 2
rhel:/connectal/examples/echo#
************* END **************************************

At 2016-01-18 01:18:10,jankcorn notifications@github.com wrote:
Are you sure that addr is 32 bits on x86? we always run 64-bit versions,
so seems peculiar.

In addition, I am accustomed to sizeof(long) == sizeof(void *), for
example, see the last line of the next-to-last paragraph of:
http://www.makelinux.net/ldd3/chp-11-sect-1
( was looking for this in the c std, but can't find similar text... :-( )

Thanks
jca

On Sun, Jan 17, 2016 at 9:00 AM, Han Wang notifications@github.com
wrote:

can you post the error message?


Reply to this email directly or view it on GitHub
<
#106 (comment)

.


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub
#106 (comment)
.

@jameyhicks
Copy link
Member

I feel like I'm hearing half of a phone conversation.

@chenm001, it would be possible to put together a simulation configuration that supports 32-bit x86, but I agree with @jankcorn that it would be better to switch to 64-bit x86. Because who knows how many other places we assumed x86 was 64bit.

@chenm001
Copy link
Contributor Author

Agree, for really world, we may use x64 OS.
In simluate enviorment, I simple workaround by modify local to 'uint64_t addr;'

@jameyhicks
Copy link
Member

If that change works, I think we could update dmaSendFd.h accordingly.

We do not have any 32-bit x86 systems to test with, so please let us know
if any other changes are required.

On Fri, Jan 22, 2016 at 7:38 AM chenm001 notifications@github.com wrote:

Agree, for really world, we may use x64 OS.
In simluate enviorment, I simple workaround by modify local to 'uint64_t
addr;'


Reply to this email directly or view it on GitHub
#106 (comment)
.

@chenm001
Copy link
Contributor Author

I will do more test and let you know later

At 2016-01-22 22:22:07,"Jamey Hicks" notifications@github.com wrote:
If that change works, I think we could update dmaSendFd.h accordingly.

We do not have any 32-bit x86 systems to test with, so please let us know
if any other changes are required.

On Fri, Jan 22, 2016 at 7:38 AM chenm001 notifications@github.com wrote:

Agree, for really world, we may use x64 OS.
In simluate enviorment, I simple workaround by modify local to 'uint64_t
addr;'


Reply to this email directly or view it on GitHub
#106 (comment)
.


Reply to this email directly or view it on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants