[haiku-development] Re: weird segfault in malloc internals when trying to call fdopen()
- From: Michael Zucchi <notzed@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 22 Oct 2009 12:50:48 +1030
2009/10/18 Alexander Botero-Lowry <alex.boterolowry@xxxxxxxxx>:
>> FWIW I got emacs to compile and run (in terminal mode). I disabled
>> dumping because I didn't know enough about haiku to make it work.
>>
> I'm actually having issues getting it to run in terminal mode. I'm
> getting an infinite select loop on keyboard input when I run temacs (the
> undumped emacs). Otherwise it kind of vaguely works. I was actually going
> to cheat and start working on the GUI mode, though I know nothing about how
> to do that or really BeAPI.. :) I like shooting blind I guess.
Have to turn off 'INTERRUPT_INPUT' in the system file. The GUI code
for each platform looks to be tacked on - a different c layer of
system related functions for each platform, that are then called from
platform specific lisp code, which is spread all over the place. It
will take quite a lot of learning about the internals to get it to
work (and explains why e.g. the gtk port took years ...).
>> If you're interested I can send you my s/haiku.h - basically I kept
>> turning stuff off/mucking about till I got it to work, but it was
>> mostly random with no prior knowledge so it is unlikely to be
>> particularly well done.
>>
> Yes, I'd love to see your work. I am going to work to get these changes
> into upstream gnu emacs as soon as I get something that resembles working
> order. I was actually about to write an email to emacs-devel@ about it.
> I think a GUI mode is extremely important, indeed I don't find emacs that
> enjoyable without it. This is compounded by the fact that the Terminal app
> is kind of buggy. For example, it handles scrolling in emacs over ssh pretty
> poorly. One thing I am interested in looking at is porting FreeBSD's
Ok, diff against 23.1 @ http://users.on.net/notzed/haiku/emacs-23.1-haiku.diff
Includes src/s/haiku.h and configure.in change, oh, and elf.h from
glibc since haiku doesn't have one. Might be incomplete - i didn't
want to include the new configure autoconf generated. Once it's
compiled it'll fail doing a hardlink, i just changed the makefile
manually to use 'cp' instead of 'ln' at that point. Because it
doesn't dump it takes a really long time to compile all the lisp too.
After make install, It runs but a bunch of stuff doesn't work
properly, e.g. shell mode resets the environment, and so on.
In GUI mode i turn off all the menus and rubbish so it's not a huge
difference to me, apart from the clipboard, but obviously gui mode
would be the target - but boy is the source a weird mess of platform
specific hooks in c called from platform specific lisp code.
> libteken to Haiku and rewriting Terminal to use it for the handling of xterm
> instructions. libteken is, for those that don't know, an implementation of the
> xterm control characters as a library that will be used for the FreeBSD
> console
> in 8. It handles all the nuances of the drawing logic, so that all the
> terminal
> code has to do is draw it to the termview.
FWIW remote xterms have been broken since xfree86 and then xorg.conf
keep changing what 'xterm' as a termtype means, so if you're logging
into a linux box blame that/use a different termtype.
I worked on gnome-terminal 1.x (specifically the terminal emulator
library it used), not that I really want to revisit anything like that
again. Basically there's no 'standard' control set, and what is used
changes over time, so it's a constant compatibility race keeping up
with various curses libraries and terminfo's, and their specific bugs.
Let alone os-specific magic keys that interfere with keystrokes or
people wanting to add menu's with keyboard shortcuts.
>> > I really didn't even try to do it, I didn't want to learn about ELF at
>> > the time ;)
>>
> I've been poking a bit, but really don't know anything about ELF, so I'm
> basically just looking around for interesting defines, etc. :)
It's just a bunch of tables (of offsets) offset from the beginning of
the file. It can be very simple, all the ro data placed together at
page offsets ready to go, or it can be all over the place, so you
really need to know plenty about the platform which complicates
things. The unexelf code has plenty of comments but in short it
expands the data segment to include the bss segment + any allocated
data and writes that out as the new executable. I think it assumes
they follow each other, but I would think elf could actually handle
whatever is actually there, assuming the dumper can discover the
layout and the system elf loader supports it (e.g. relocs). I think
one reason emacs has its own sbrk based allocator is to make sure the
memory layout is known on lots of different platforms.
objdump will show you all the elf data quite well with the right
switches, along with the elf man page for glibc.
2009/10/18 Michael Crawford <mdcrawford@xxxxxxxxx>:
> Does Haiku even provide the sbrk system call?
Yes it's there, but it doesn't implement sbrk(0) -> return highest
valid address. Since emacs (and I presume pretty well anything that
would probably ever want to use sbrk()) relies on this, it isn't
useful.
I kinda hit a brick wall of apathy once I got to the GUI parts, I
think I got some haiku code to open a window, write some text, and
read key events and then found something to do in the garden instead
of working out how to hook it into emacs.
Michael
Other related posts:
