OS/2, eCS & ArcaOS - Technical > Programming

Only short exceptq report although .xqs file was there, why?

<< < (2/4) > >>

Lars:
For Watcom I find this:


--- Code: ---[c:\watcom\binp]wstrip
Open Watcom Executable Strip Utility Version 2.0beta1 Limited Availability
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Usage: wstrip [options] input_file [output_file] [info_file]
options: (/option is also accepted)
        -q     don't print informational messages
        -n     don't print warning messages
        -r     process resource information rather than debugging information
        -a     add information rather than delete information

        input_file:  executable file
        output_file: optional output executable or '.'
        info_file:   optional output debugging or resource information file
                     or input debugging or resource information file

--- End code ---

Something like:
wstrip PCM9362_AnetCom.exe PCM9362_AnetCom.exe PCM9362_AnetCom.dbg

Looks like "info_file" would then contain that debugging data. However, I am not sure if Watcom will do at all because it does not produce either the (proper) Codeview or HLL debug format that exceptq would understand. Unless excdeptq was written to also support the Watcom debugging format but I doubt that. You will have to try out.

Lars:

--- Quote from: Andi B. on January 22, 2022, 01:57:41 pm ---Looking at the map file I see at the failing address watcoms MemAllocator -

--- Code: ---Module: P:\watcom/lib386/os2\clib3r.lib(nmemneed.c)
0002:0000ad60  __nmemneed_
Module: P:\watcom/lib386/os2\clib3r.lib(mem.c)
0002:0000ad70  __MemAllocator
0002:0000ae20  __MemFree
Module: P:\watcom/lib386/os2\clib3r.lib(grownear.c)

--- End code ---
Seems a bit strange to me. Puzzling....

--- End quote ---

That does not mean much. You might have a bunch of functions marked as "static" which never show up in the map file and consequently, they don't show up in the .XQS file. On the other hand, "__MemAllocator" and "__MemFree" are close enough to each other to not fit in yet an additional "static" function.

The full exceptq will give you the source file and line which is very convenient and even works if the trap location is in a function marked as "static".

What I think is a possible problem is if you use "malloc" from a DLL/EXE using its version of the RTL and therefore heap management and then use "free" from a DLL/EXE using a different version of the RTL and therefore heap management.
That can be a problem if for example you allocate a block of memory from an executable written with Watcom and then pass on that pointer to a DLL written with GCC to have it freed. That can blow your app. Know your enemies.

And then, for Watcom, it's about using the register based RTL vs. the stack based RTL. You are using the register based RTL and hopefully you have been compiling your code to use register based argument passing (but I would think so, otherwise you'd have a whole bunch of problems and not only one ...).

Dave Yeo:
Hi, the xqs files should be enough to create a trp report and it looks like you are correctly creating them. And of course wl.exe is a patched version of wlink.exe to handle dwarf debugging code. IIRC, (have to look at the mozilla source), the symfile directive creates the dbg file. You do have to build with -g to get the debug info to begin with.
To double check the debug status, try running the binary under an OS/2 (not Watcom) debugger.
Perhaps simply exceptq's exception handler isn't handling the exception correctly and it is falling through to the default exception handler, which creates the entry in popuplog.

Dave Yeo:
OK, use something like 'LDFLAGS=-Zlinker option symfile=xxx.dbg' and -g in both CFLAGS (CXXFLAGS) and LDFLAGS to get the dbg file.

Andi B.:
I played a bit and think I did set up all right the first time. I had tested exceptq reports with watcom previously. What I now think may be the problem is this peace of code I copied from the bloatcom library I found ages ago on hobbes I think. This is the start of new thread which I have added exceptq handling in this way -

--- Code: ---static void _System receive_thread(ULONG param)
{
  EXCEPTIONREGISTRATIONRECORD exRegRec;
  PCOMPORT cp = (PCOMPORT)param;
  APIRET rc = NO_ERROR;
  const ULONG cbTempMax = 65536;
  ULONG cbTemp = 0;
  void *pTemp = malloc(cbTempMax);

  LoadExceptq(&exRegRec, NULL, NULL);


--- End code ---
I now see malloc is called in this thread before LoadExceptq. If malloc fails when this thread is created then exceptq probably can't do it's job. No clue why malloc should fail but the trap report indicates this. Of course I've changed this code now.

Thanks for the infos. One question - what's the advantage from creating a .dbg file instead .xqs? I got the impression most newer software use .xqs, right?

Moreover as we are here - what I still didn't get to work is building with watcom and source level debugging with idebug. wl creates hll debugging info (tested with compiling with gcc and linking with wl). But wcc386 don't create proper debug info here no matter which switches I use.

Currently I usually use this settings -

--- Code: ---wcc386 -zq -wx -ef -of -Ip:\watcom1.9\h\os2;e:\c\include -d2 -d__DEBUG__ -d__DEBUG_PMPRINTF__ main.c
wl NAME main SYSTEM os2v2 OPTION MAP=main.watmap debug all lib pmprintf.lib file { main.obj }

--- End code ---

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version