Ros-dev

ros-dev@reactos.org

5788 discussions

RE: [ros-dev] Proposal to change .sym files

by Murphy, Ged (Bolton)

Ge van Geldorp wrote: > If symbolic info was present in file.nostrip.ext (i.e. it was compiled with > -g, which at present implies DBG := 1), then it will also be present in > file.ext. So, the backtrace on e.g. BSODs should print the function > name/source file/source line in addition to the address. Which means we > won't have to use addr2line very often. If there was no symbolic info in > file.nostrip.ext, addr2line wouldn't be of help anyway. I like this idea. Me, Alex and Steven were discussing something similar the other day in IRC. I never expected things to move so fast :) Ged ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

19 years, 11 months

Proposal to change .sym files

by Ge van Geldorp

In anticipation of doing some work on performance issues, I've been experimenting with our kernel profiler the last few days. For those who don't know, you can activate the profiler by including the /PROFILE option on the command line. On each timer interrupt the current EIP will be saved, after 30 sec a background task will convert the saved EIPs to function name/file name, count how often each function name occurs and write the results to a file %system_root%\profiler.log. There are 100 timer ticks per second, a 30 sec measuring interval will therefore generate 3000 EIPs. This works very nice, but I'm running into one problem on my 300MHz test machine: conversion of the EIPs to function name by the background thread takes about 60 sec. Almost all of that time is spent looking up the correct .stabs entry from the info in the .sym file. This is done using a linear search. Since there can be 100000 .stabs entries in a .sym file, going through these for each of the 3000 measurements can mean 300000000 compares. Even worse, two passes are made through the .stabs list for each measurement, one to find the function name and one to find the file name. No wonder this takes 60 sec. So, we need to improve the search. I've done some simulations, and when I use a binary search instead of a linear search, the performance is dramatically better. Time required to convert all measurements drops from 60 sec to 0.06 sec, a 1000 fold improvement. To be able to use a binary search, the information in the .sym file needs to be sorted and uniform (each element contains the same type of data) which it currently isn't. We have .stabs entries defining a function (N_FUN), source line (N_SLINE) and source file (N_SO). Currently, we only use the .sym files to convert an address to function name/file name/source line, not the other way around (no function name to address for example). I'd like to drop using the .stab format in the .sym files and change to the following format: +----------+ |header | +----------+ |symentries| +----------+ |strings | +----------+ The header would just contain the start location and number of symentries plus start location and total size of the strings. Each symentry would have the following info: typedef struct tagSYM_ENTRY { ULONG_PTR Address; ULONG FunctionOffset; ULONG FileOffset; ULONG SourceLine; } SYM_ENTRY, *PSYM_ENTRY; where Address is an address relative to the beginning of the module, FunctionOffset and FileOffset are offsets from the beginning of the strings section and SourceLine contains the source line number. The symentries are sorted by Address (done by rsym). Each Address would only appear once, and information would be made as complete as possible (e.g. when creating the symentries from the .stabs in the .nostrip.exe file each FunctionOffset would be set to point to the function name from the most recently encountered N_FUN .stab). This will allow us to retrieve all 3 pieces of information (function name, file name and source line) by doing just a single binary search. Comments, thoughts, objections? Gé van Geldorp.

19 years, 11 months

gcc/msvc int64 suffix/LARGE_INTEGER portability macros

by Gunnar Dalsnes

Suggested gcc/msvc portability macros: #if defined(_MSC_VER) #define MK_INT64(a) (a) #define MK_UINT64(a) (a) __inline LARGE_INTEGER MK_LARGE_INTEGER(__int64 i) { LARGE_INTEGER li; li.QuadPart = i; return li; } #define LARGE_INTEGER_NULL MK_LARGE_INTEGER(0) #elif defined (__GNUC__) #define MK_INT64(a) (a##LL) #define MK_UINT64(a) (a##ULL) #define MK_LARGE_INTEGER(a) ((LARGE_INTEGER)(LONGLONG)a) #define LARGE_INTEGER_NULL ((LARGE_INTEGER)(LONGLONG)0LL) #else #error Unknown compiler for LARGE_INTEGER/int64 macros #endif example: LARGE_INTEGER test1(LARGE_INTEGER arg) { return MK_LARGE_INTEGER(arg.QuadPart+3); } LARGE_INTEGER test2() { LARGE_INTEGER a = LARGE_INTEGER_NULL; a.QuadPart += test1(LARGE_INTEGER_NULL).QuadPart; a.QuadPart += MK_INT64(1152921504606846975); return LARGE_INTEGER_NULL; } What do you think? Gunnar

19 years, 11 months

ReactOS DOS subsystem

by AzeemArif

Hello ROS-Devs, I've been sharing some thoughts about DOS subsystem on ReactOS forum. I am pasting my last post (http://reactos.com/forum/viewtopic.php?p=2864#2864 ) <http://reactos.com/forum/viewtopic.php?p=2864#2864> here for your comments ======================================================== hello, I am back with my silly posts Smile But this time, after seriously reading and experimenting with FreeDos and DosEmu code. As many people suggested FreeDOS as an option to run as ReactOS subsystem, I concentrated more on FreeDOS. Something I came to know are 1) We need ReactOS DOS/Win16 subsystem so that we can run 16bit DOS applications on ReactOS. 2) FreeDOS itself is 16bit system 3) Compiling FreeDOS code with 32bit compiler is so difficult that it gave birth to a new project FreeDOS-32 (I tried compiling FreeDOS code with MinGW with no success) 4) FreeDOS-32 is in its infancy. Currently it can't even run simple DOS applications 5) DOSEmu is really slow Please give your valuable suggestions. AcetoliNe: I agree with your last post. ===================================================================== ~AzeemArif (ReactOS IRC channel - "azar")

19 years, 11 months

ReactOS DOS subsystem

by AzeemArif

19 years, 11 months

RE: [ros-dev] msvcrt/crtdll "merge"

by Waldo Alvarez Cañizares

Hi Gunnar: >And about the strlen=ntdll.strlen stuff. Forwarded functions doesnt show >up as imported because they arent really imported, so this is normal. I think that it is not normal. The better way should be to really forward them, this is just half baked stuff. If you are not going to forward it, I think that it would be better to not declare them as such because that can cause confusion. >Dont understand what XP's ntdll exporting "WindowsCE" functions has to >do with anything? Was just a comment about ntdll, they are exported and nothing is mentioned in msdn. I said that because I think ntdll is very close to the runtime. Best Regards Waldo

19 years, 11 months

RE: [ros-diffs] [jimtabor] 13373: Remove building of Advpack for now.

by Casper Hornstrup

What is the purpose of this regression? Also, this broke "make bootcd" Casper ________________________________ From: ros-diffs-bounces(a)reactos.com [mailto:ros-diffs-bounces@reactos.com] On Behalf Of jimtabor(a)svn.reactos.com Sent: 1. februar 2005 00:34 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [jimtabor] 13373: Remove building of Advpack for now. Remove building of Advpack for now. Modified: trunk/reactos/Makefile ________________________________ Modified: trunk/reactos/Makefile --- trunk/reactos/Makefile 2005-01-31 22:13:43 UTC (rev 13372) +++ trunk/reactos/Makefile 2005-01-31 23:33:34 UTC (rev 13373) @@ -54,8 +54,8 @@ DLLS_SHELLEXT = shellext # User mode libraries -# libpcap packet epsapi -DLLS = acledit aclui advapi32 advpack cabinet cards comctl32 crtdll comdlg32 d3d8thk dbghelp expat fmifs freetype \ +# advpack libpcap packet epsapi +DLLS = acledit aclui advapi32 cabinet cards comctl32 crtdll comdlg32 d3d8thk dbghelp expat fmifs freetype \ gdi32 gdiplus glu32 hid imagehlp imm32 iphlpapi kernel32 lzexpand mesa32 midimap mmdrv mpr msacm msafd \ msgina msi msimg32 msvcrt20 msvideo mswsock netapi32 ntdll ole32 oleaut32 oledlg olepro32 opengl32 \ packet psapi riched20 richedit rpcrt4 samlib secur32 setupapi shell32 shlwapi snmpapi syssetup twain \

19 years, 11 months

RE: [ros-dev] ACPI status

by PETREOLLE Sylvain

It works here, computer is put into low power state everytime you click on logoff. Usurp (aka Sylvain PETREOLLE) Service de Production & d'Exploitation Informatique GEFCO - #DMIT/DATO/PSI/PEI Mail : <mailto:exploit@gefco.fr> Tel : 01.49.05.29.29 -----Message d'origine----- De : Gge [mailto:gerard.gatineau@laposte.net] Envoyé : vendredi 28 janvier 2005 07:59 À : ReactOS Development List Objet : [ros-dev] ACPI status I built Ros with ACPI=1 but the feature is not working (in real hardware) as the computer does not go into low power state . At boot the debug messages displayed are : DriverBase for acpi.sys : 9ce1300 Advanced Configuration and Power Interface Bus Driver ACPI: System firmware supports: +------------------------------------------------------------ | Sx states: +S0 +S1 -S2 -S3 +S4 +S5 +------------------------------------------------------------ What is the status of the ACPI feature ? Is it supported actually ? Best regards Gerard _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev ---------------------------------------------------------------------------- Ce message ainsi que toutes pièces jointes (le "message") sont confidentiels et sont exclusivement destinés à l'usage de la personne à laquelle ils sont adressés. Tout point de vue ou toute opinion contenus dans ce message expriment la pensée personnelle de leur auteur et ne représentent pas nécessairement la position des sociétés du Groupe GEFCO. Si vous n'êtes pas la personne à laquelle ce message est destiné, veuillez noter que vous avez reçu cet e-mail par erreur et qu'il vous est strictement interdit d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message. Si vous avez reçu ce message par erreur, merci de contacter la personne qui vous l'a adressé et de l'effacer immédiatement. Les sociétés du Groupe GEFCO déclinent toute responsabilité en cas d'altération, de modification, d'édition, de diffusion sans autorisation de ce message ou en cas d'affection de ce message par un virus. This message and any attachments (the "message") are confidential and intended solely for the use of the individual to whom they are addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the GEFCO Group of Companies. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this message is strictly prohibited. If you have received this message in error please contact the sender and delete the message immediately. The GEFCO Group of Companies shall not be liable for the message if altered, changed, falsified, edited, diffused without authorization or affected by any virus. ----------------------------------------------------------------------------

19 years, 11 months

Re: [ros-svn] [navaraf] 13369: Force non-inlining of ctype functions even in OPTIMIZED builds. Fixes bug #497.

by Alex Ionescu

navaraf(a)svn.reactos.com wrote: >Force non-inlining of ctype functions even in OPTIMIZED builds. Fixes bug #497. > > >Updated files: >trunk/reactos/lib/kjs/makefile > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > Aren't you forcing non-inlining of EVERY function by doing this? Isn't it better to enable the special no ctype inline macro? Best regards, Alex Ionescu

19 years, 11 months

RE: [ros-dev] msvcrt/crtdll "merge"

by Waldo Alvarez Cañizares

Hi Gunnar: Great! less duplicated code == better code I had planning to report this about msvcrt/crtdll the first chance I could get to read my e-mail, but now that you talked then there's no better chance than this I think. I was playing with msvcrt dll a couple of days ago because I was trying to test some apps against it and to maybe find some of the multithreading issues it contains. Well I dropped it because I really had no time but one thing I noticed is that there are some entries in the .def file something like this strlen=ntdll.strlen only strings routines if I remember well. Now after I got the binary file (.dll) I was inspecting it with LordPE, a tool to sniff every detail of PE's and saw that actually those routines are not imported by crtdll (maybe because of the strings.a statically linked) also I saw that msvcrt.dll is importing functions from itself funny that is something I never saw before (Is ROS parsing the exports table before the imports one? Just curious). But worst there are 2 references to msvcrt with different functions that the -O flag when passed to the linker can't fix. I have seen this before in some applications compiled with mingw (freecraft for example. Could be this an unnoticed bug in mingw's linker? If It is, it doesn't harm but it sucks to not have it the better way you can if it is easy to do it). btw I was also looking for string routines exported by ntdll in order to squeeze a bit more both libraries and noticed in XP's ntdll some functions that at the beginning I thought were mistyped (It would not be the first time) but when I took a look at msdn Tada! WindowsCE functions, nothing about XP/2k... but there they ARE. Please do not forget to fix those problems with exports if you can, or anyone with a chance, those libraries stink a lot. I still don't understand every detail on how the whole thing works: build system, linker... so this is a "I don't know how to fix", at least for now. Best Regards Waldo Alvarez ________________________________ From: ros-dev-bounces(a)reactos.com on behalf of Gunnar Dalsnes Sent: Wed 1/26/2005 8:19 PM To: ReactOS Development List Subject: [ros-dev] msvcrt/crtdll "merge" Hi, I'm currently "merging" msvcrt and crtdll (again). I'll move msvcrt into a library lib\crt and have msvcrt and crtdll link against it. Only dllmain.c will be left in msvcrt/crtdll. Most of (99.9%) crtdll will be dropped. It all seems to work nicely. One problem thou: I ran into some header problems, where i relied on some stuff in include\msvcrt\string.h but no matter what, mingw\include\string.h were included instead (and they both defined _STRING_H_). After looking at the headers in inlcude\msvcrt they all seem to be ripped from mingw. Does anyone know why they were put in include\msvcrt when mingw has headers for all of this stuff? Can i just remove them (include\msvcrt)? I looked at many depends files and saw most files depend on many mingw headers. Is this correct? Should we depend on mingw headers at all? Gunnar _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev

19 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev