This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
[PORT] BeOS port problem and suggestion
- From: "Thierry Delhaise" <delhaise dot t at wanadoo dot fr>
- To: "Binutils list" <binutils at sources dot redhat dot com>, "GCC List" <gcc at gcc dot gnu dot org>
- Date: Thu, 19 Sep 2002 13:51:51 GMT
- Subject: [PORT] BeOS port problem and suggestion
Hi the list,
When Be was maintening its own gnupro version, they took care to handle
some specifics area of BeOS inside them port.
One is a problem with the BeOS fseek that rely on BFS filesystem : on
BFS when you fseek on a new create file, none of offset is set with
zeros. So if you fseek/seek and you don't use the pass area, when you
will write your file, you will have some garbage inside.
I would like to handle this problem like this :
First modify the configure tools chain and add a test to verify how
fseek/seek work on the host platform. If I detect a problem (such the
BeOS one), use a bfd_seek()/bfd_fseek() functions in place of seek()/
fseek().
I will provide code for those two functions.
Questions :
Any advice on this ?
Where and how I call the source file where I'll store this two
functions ?
Since bfd is common to binutils/gcc, where I will send my patchs ?
Since the focus is set on gcc 3.x does my patch could be include even
in the 2.95.3 tree ? (We currently use 2.95.3 since the ABI change made
in 3.x don't allow us for now to use this compiler tree, but we plan
it)
General Questions (may be OFF TOPICS ):
Be was using a special ABI tag :
# Configuration ABI OS ABI version
# ------------- ------ -----------
*-.*-linux.* 0 2.0.0 # earliest compatible kernel
version
*-.*-gnu-gnu.* 1 0.0.0
sparc-sun-solaris2.* 2 2.0.0 # just an arbitrary value
i[3456]86-.*-beos.* 10 4.0.0 # not official
As you can see, it was not official.
Does the status of this ABI tag is allways unofficial ? Where can I ask
to register this one ?
THX in advance
Thierry (BeFree)